Ogledujete si pomoč za različico :
The following checklists guide you, through all phases of the project lifecycle, to a successful project delivery. They are intended as a set of best practices for project delivery. To deliver high quality services, you need to complete all items in the checklists, preferably in order.
The checklists contain Input elements and Output elements. There is no 1:1 correlation between inputs and outputs; for example, a collection of several inputs can result in one output.
Prenos
Prenos
The preparation of your project requires a collection of requirements, a roadmap and other up-front work which should result in:
- a validation of the project
- a budget approval
| Input | Output | ||
| Customer roadmap |
High level solution design | ||
| Scope document | Architecture draft | ||
| Return On Investment (ROI) expectations | Hardware estimates | ||
| Initial experience designs requirements | Performance KPIs | ||
| Business requirements documentation | Project efforts | ||
| Technical requirements documentation | |||
Opomba:
Key Performance Indicators (KPIs) are:
- Number of parallel authors and users (concurrency)
- Response times
- Number of assets per day (average and peak)
- Number of page modifications per day (average and peak)
| Input | Output | ||
| Scope document | Validated budget plan | ||
| High level solution design | |||
| Hardware estimates | |||
| Project efforts | |||
| Requirements documentation | |||
The planning of your project must start with a good understanding of the project by everyone involved. You also need to have a sound knowledge of the risks your project will be exposed to, and a plan on how you will communicate throughout. This will provide a sound basis for the start of your project. Completing these 4 checklists will help you cover the main points:
| Input | Output | ||
| Customer overall project roadmap | Performance KPIs document | ||
| Project scope definition | Project management understands the scope of the project and the expectations | ||
| ROI expectations | |||
| Initial experience designs | |||
| Business and technical requirements documentation | |||
| High level solution design | |||
| Architecture draft | |||
| Hardware estimates | |||
| Historical performance KPIs and expectations | |||
| Relevant contract terms | |||
Opomba:
The project management team needs to have a clear understanding of:
- the throughput for the site
- the numbers of visitors including peak times (for example events iDay, Superbowl and so on)
- the page render times millisecond granularity, including third party integrations
- the asset delivery
- the caching strategy
| Input | Output | ||
| Identify critical key solutions and functionalities | Technical risk factors are known and understood | ||
| Customer roadmap project timeline | Adjustment of the scope and features required | ||
| Technical and Business Risk Assessment | Results and business decision proposal | ||
| Proof of concept (POC), design and implementation | Technical risk factors verified | ||
| Test and verify POC against Requirement Documentation | |||
Opomba:
The identification of solutions that can be a potential risk (for example MSM, Commerce integration, and so on) is important. The result will be the basis for reporting into the business whether the full requirements can be implemented or even whether other concepts need to be adapted. In case the solution concept is fraught with risks, the business requires a decision template on how to deal with those key requirements.
| Input | Output | ||
| Definition of internal and external Stakeholders | Issue tracking process is set up and integrated | ||
| Issue Tracking System and processes from involved parties | Project status reports within a defined cadence | ||
| Status Report format definition | |||
| Reporting Cadence | |||
| Input | Output | ||
| Customer roadmap | Project team understands project and expectations | ||
| Project scope document | Hardware will be available to fulfill requirements | ||
| ROI expectations | Agreement on KPIs, defined as goals for project | ||
| Initial experience designs | Project team is aware of the communication plan | ||
| Requirements documentation | |||
| High level solution design | |||
| Architecture draft | |||
| Hardware estimates | |||
| Performance KPIs | |||
| Timeline and milestones | |||
| Project organization and communication | |||
Opomba:
For more information about kick-off requirements, see also:
Before the actual development, there are several prerequisites to ensure that your team is ready to go for it:
| Input | Output | ||
| AEM technical trainings | Staff trained | ||
| AEM certification | Certified AEM Component Developers (75%) | ||
| AEM Lead Developer Certified (minimum of 1) | |||
| AEM Architect Certified (minimum of 1) | |||
| Input | Output | ||
| Initial experience designs | Content architecture definition | ||
| Requirements documentation | Feasability confirmation on KPIs | ||
| High level solution design | |||
| Architecture draft | |||
| KPIs definition | |||
Opomba:
This checklist should result in a definition of:
- Basic structures (content, assets, campaigns, etc.)
- Multi site and multi language structures (MSM, Translation, etc.)
- Supportive content (tags, ...)
- Cached versus uncached content
| Input | Output | ||
| Requirements documentation | System architecture definition | ||
| High level solution design | Run baseline tests on an out-of-the-box installation of AEM, using preferred automation testing suite, confirm deviation to plan and adjust. | ||
| Architecture draft | How KPIs for performance and scalability can be met? | ||
| Hardware estimates | |||
| KPIs definition | |||
| Sign off with lead developer checklist | |||
| Performance and scalability concept | |||
Opomba:
This checklist should cover:
- Hardware Sizing Guidelines
- Required environments (dev, stage, prod, other?)
- Servers and processes for each environment
- Maintenance activities (Datastore GC, TarPM Opt, ...)
- Matching KPI's from Sales Handover
- Dispatcher caching
- Clustering Publish/Authorshare
- Most important: Performance for the client-side (JS minify, concat, css sprites, total number of http request, and so on)
| Input | Output | ||
| Requirements documentation | Run baseline tests on an out-of-the-box installation of AEM, using preferred automation testing suite, confirm deviation to plan and adjust | ||
| High level solution design | List of components and templates to be developed, dialog definition, together with important properties (name and type) for all of these | ||
| Architecture draft | Implementation concept for specific (large) modules of AEM when used | ||
| Hardware estimates | |||
| KPIs document | |||
| Component and template concept | |||
| Special functionality concept | |||
Opomba:
This checklist should cover:
- Basic code structure for project
- Code artifacts (bundles, packages, ...)
- Templates/components breakdowns and their relations
- Required customizations (high level, specific overlays later)
- Design of general workflows that the solution must support (content creation, approval, publishing, transformations, imports, exports, ...)
- Special attention on complex modules, such as MSM, Commerce, third party integration
| Input | Output | ||
| Third party integration requirements | Technical concept for third party integration | ||
| Service level agreements defined and in sync with the platform | Support process and emergency plan | ||
Opomba:
This checklist should cover:
- Technical concept on how the third party system will be integrated (offline/online, client-side/browser-side)
- Fail-over handling when third party system is down
| Input | Output | ||
| Initial experience designs | Test concept documentation | ||
| Requirements documentation | Test plan | ||
| High level solution design | Customized Tough Day, covering customer use cases | ||
| Transform performance KPIs into Tough Day | Formalized acceptance tests | ||
| Use cases / customer stories | User stories, dissected into click paths, to generate executable test cases | ||
Opomba:
Tests automated with, for example, Selenium or AEM Developer mode.
| Input | Output | ||
| Setup support processes (Partners/Customers/Adobe) | Staff understands the support processes from Adobe | ||
| List of users require access to Adobe Support Portal | Staff has sufficient permission in Support portals | ||
| Definition of escalation process | Staff understands escalation processes | ||
| Request for setting up project section in Adobe Support Portal | Project setup in Adobe Support Portal | ||
Successful development is crucial to your project. The first step towards this involves completing the following checklists:
| Input | Output | ||
| List of standard development tools to be used in the project | Development environment set up | ||
| High level solution design |
Development system ready | ||
| Architecture draft | |||
Opomba:
A typical environment consists in an issue tracking system, an IDE (such as Eclipse), Maven, Jenkins (for continuous integration), GIT/SVN, Archiva/Nexus.
Opomba:
- be ready for development releases and nightly builds
- preferably have similar sizing as the production system for performance tests
| Input | Output | ||
| System architecture definition | Production system ready | ||
| Run Tough Day test on final production setup | Baseline performance verfied with Tough Day Test | ||
| Disk performance test | Disk performance (DiskBenchmark) result with a valid pattern | ||
Opomba:
To help you achieve this checklist, see:
- Tough Day test
- Best Practices for Quality Assurance
- Disk Benchmark (especially when Network filesystem will be used)
| Input | Output | ||
| Integration test setup | Automated deployment process | ||
| Role Definition for IT and/or Unit Tests | |||
Opomba:
This checklist should cover:
- Automated process to move application from dev to test to prod (and content the other direction)
- Definition on which level developer should test (i.e. IT, Unit)
| Input | Output | ||
| Document customizations which affects upgrades, hotfixes | Operations manual (user guide) | ||
| Document operational tasks | |||
| Release notes | |||
Opomba:
The operations manual must contain:
- Information about changes that may affect installed systems and content
- Information about customizations and overlays that may affect upgrades, hotfixes, etc.
- Information about operations related tasks (configuration, etc.)
| Input | Output | ||
| Release running on production | Functionality of the application is accepted by stakeholders | ||
| Acceptance test | Formalized checklist for customer handover; ideally automated and run on a nightly basis on snapshot, yielding results, sent to project manager and development team | ||
Opomba:
Final check for functional/workflow issues. It has to be verified with every development sprint.
| Input | Output | ||
| Performance KPIs | Tough Day or equivalent test suite results, must be passed | ||
| Use cases definitions | Validated test script against realistic and expected load | ||
| Real content for testing | Customized Tough Day or equivalent test suite adapted to real content and result comparison to OOTB test run | ||
| Full loaded test suite | Automated, or run manually on a regular basis | ||
| 70% of the requests for pages respond in less than 100ms | |||
| No pages respond slower than 1 second. | |||
| Acceptance from business stakeholders | |||
Opomba:
For more information about performance tests, see:
| Input | Output | ||
| AEM Admin Training | Trained system administrators | ||
| Standard author training | Trained authors/users | ||
| If required: specific training material for application and/or site | End users trained | ||
Opomba:
See Adobe AEM Training to find the trainings in the course catalog.
| Input | Output | ||
| Security checklist | Security test report | ||
| Signed from system owner | |||
| Input | Output | ||
| List of security issues | Security issues fixed | ||
| Security checklist | Security enabled | ||
| Penetration test | Penetration test passed | ||
| Fallback system | System and process available for switching back | ||
| Fallback procedure tested | Fallback Procedures passed testing | ||
| Go-live schedule | Adobe Support is informed about the go-live schedule | ||
You need to define roles (such as author, contributor, administrator) with specific permissions for your users. It is also mandatory to maintain and monitor your system as the project proceeds and to be able to backup and restore in case of emergency:
Opomba:
- List of roles (i.e. groups) with read/write access definitions for each.
- Privileges like replicate defined.
- For users with minimal privileges, workflows should be defined.
- Users in the editor group should not have admin rights nor be part of the administrators group.
For more information, read User Administration and Security.
| Input | Output | ||
| Disk space monitoring | System monitoring enabled | ||
| CPU monitoring | Threshold and interventation enabled | ||
| Disk I/O monitoring | External system monitoring enabled | ||
| Network bandwith monitoring | |||
| DataStore garbage collection enabled and tested | |||
| Repository optimization | |||
| External system monitoring | |||
| Request monitoring | |||
Opomba:
See also Monitoring and Maintenance for more information.
| Input | Output | ||
| Backup of author and publish instances | Recovery plan and procedures documented | ||
| Restoration tested and documented | |||
| Cluster: steps for cloning were tested and are documented | |||
Opomba:
In an emergency situation, a full rollback/restoration must be available to secure the production use of AEM.
Objav v storitvah Twitter™ in Facebook ne urejajo pogoji pogodbe Creative Commons.