Vous consultez actuellement l'aide de la version:
It is advisable to plan tasks throughout your project:
- The following tables show possible tasks within an AEM project.
- For each phase (some of which might apply to multiple iterations), the main actions are listed; within these the possible tasks and/or issues to be considered.
- These lists are meant as quick-reference, they do not (cannot) offer a 100% comprehensive list of all possible tasks, but are meant to act as a springboard.
- The list of tasks will vary with each project.
You can make your initial estimates of time and effort for (high-level) task definitions; these should include an indication of to who (customer or partner) will do what and when. Detailed planning can then relate available or required resources to deadlines and costs.
Remarque :
Certain of the comment fields show the example proportions used to calculate effort when there is a direct relationship between tasks.
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Confirm details of the Sales Agreement | Confirm all technical details agreed and/or discussed. | |
| Kick-off Workshop | ||
| Project Concept | ||
| Ensure that the Corporate Identity is available and clearly defined. | ||
| Technically review the Proof of Concept. | ||
| Confirm products and versions to be used; for example, Sites, Assets, Communities, Commerce. | ||
| Define any integrations with external applications. | ||
| Encourage the customer to view the entire process as a Project implementation (as opposed to a pure Product implementation). | ||
| Architecture Concepts (Hardware / Software / System configuration) | ||
| Required system availability | ||
| Clusters | ||
| Disaster recovery | ||
| Centralized data storage | ||
| Classification of data, and any access requirements | ||
| Integration in a secure server landscape | ||
| Target Metrics (e.g. visitors, hits, data volume, etc) | ||
| LDAP failover | ||
| Buffer to cover growth forecast | ||
| Organizational responsibilities | ||
| Platform / Browser requirements | ||
| Connectors | ||
| Review of the internal architecture | Second opinion. Use as opportunity for knowledge transfer. | |
| Feasibility Analysis | ||
| If necessary and requested by the customer, a feasibility study and/or prototype can be made. | ||
| Project Handbook (with specification) | ||
| Clearly define the role of anyone involved in the project; including steering committees, project teams, development teams, support contact, etc. | ||
| Define any specific processes and/or tools to be used during the project. For example, customer specific processes, bug and feature tracking tools, etc. | ||
| Official acceptance sign-off by both customer and project team is recommended. | ||
| Project Planning | ||
| Scheduling of regular (intermediate) releases for customer testing and assessment. | ||
| Schedule tasks according to resources available. Consider which tasks can be performed in parallel, any independencies between tasks, resource availability and the experience level required to actually perform the task. | ||
| Make time / effort estimations; these can be fine-tuned as the project progresses. | ||
| Hardware requirements | ||
| Plan the multiple deployments (soft and hard launches) to cater for performance monitoring and training. | ||
| Total Concepts and Planning |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Detailed Requirement Specification | ||
| Help the customer define their requirements in the form of Use cases. | ||
| Define any conventions used; e.g. naming, structure, programming guidelines. | ||
| Define any exclusions being made. | ||
| Indicate the Copyright, Licenses and Disclaimers. |
||
| Define the detailed requirement and functional specifications, covering all aspects of the project (including other tasks listed in this table) and clearly highlighting what has been requested, and what will be delivered. | ||
| Official acceptance sign-off by both customer and project team is recommended for this document / document set. | ||
| Total Technical Specification and Design |
| Action |
Details / Issues to be considered / Comments | Effort Estimation |
| Globals | Setup of the Global Framework and Development Environment | |
| Design parameters and settings | ||
| Structural preparation (location of components, templates, etc) | ||
| Components | ||
Standard components (e.g. Text, Image, Column Control, List, Download, etc). See the Default Components for a list of all standard components. Customer specific components (e.g. contact paragraph, RSS-feed, eCards, navigation, etc) |
A rough estimation of 2 - 4 hours for each component atom will cover all development requirements. This can only be used for an initial estimate, an experienced AEM developer should make the detailed analysis. | |
| Templates | ||
| Templates for the landing page and main content page types (average circa 5) | ||
| Other standard functionality | ||
| LDAP / Active Directory connections / Single Sign On | ||
| Portal Integration | ||
| Closed User Groups | ||
| Backup / Versioning | ||
| HTML Integration | ||
| JavaDoc documentation | ||
| Notifications | ||
| Multi-language capabilities | ||
| Workflows | ||
| Linkchecker | ||
| Web statistics | ||
| Content Importer (Word, XML, etc) | ||
| Media Library / Assets | ||
| Web Access requirements (see also http://www.w3.org/WAI/ ) | ||
| Customer specific functionality | ||
| OSGi services | ||
| Migration Tools | ||
| Subtotal Development | ||
| Developer Testing / QA | 15% of Development | |
| Follow-up / clarification during development | 10% of Development | |
| Documentation | 15% of Development | |
| JavaDoc Documentation | 10% of Development | |
| Support of customer development team | ||
| Total Development |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Functional Testing (customer) | ||
| A Test Plan should be documented detailing test cases, each scenario, expected and achieved results. | ||
| Performance Testing | ||
| Initial performance tests can be made on the test environment. These must be repeated during deployment, then integrated into ongoing monitoring processes. | ||
| Bug-fixing | 15% of Development | |
| Total Testing |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Analysis | ||
| Preparation and Tests | ||
| See Post-deployment Tasks. | ||
| Total Content Migration |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Installation - Development Environment | ||
| Installation - Development Tools | ||
| Installation - Test Environment | ||
| Installation - Production Environment | ||
| Installation - Web-server / Dispatcher | ||
| Configuration (with initial Monitoring) | ||
| System parameters | ||
| User authorization | ||
| Total Deployment |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Performance Tuning | ||
| (Basic) Performance testing, analysis and tuning | ||
| Content Population / Migration | ||
| Automatic content load (e.g. from Word into AEM) | ||
| See Content Migration | ||
| Total Post-Deployment |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Preparation of training material | For all required groups; for example, authors, administrators, support. | |
| Workshops | For all required groups; for example, authors, administrators, support. | |
| Total Training |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Handover to customer operations | Training, assistance during deployment(s), at the switch-over and ongoing. |
|
| Handover to customer support team |
Training, assistance during deployment(s), at the switch-over and ongoing. |
|
| Coordinate with Adobe Customer Support Team | Keep informed of status. When required create Daycare account. |
|
| Total Maintenance/Support |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Define (and agree) on acceptance test cases | ||
| Define when / how often the acceptance tests will occur; for example, on a regular basis, for each milestone, or only at project end? | ||
| Define exactly what constitutes success and failure for each individual test case. | ||
| Perform the Acceptance Tests | ||
| Total Acceptance Tests and Sign-off |
| Action | Details / Issues to be considered / Comments | Effort Estimation |
|---|---|---|
| Confirm details of the Sales Agreement | ||
Need:
|
||
Check:
|
||
| Ongoing Project Management and Governance | ||
| 20% of project costs | ||
| Communication and Meetings | ||
| Regular Project Reporting and status reports | ||
| Controlling - time and budget | ||
| Legal | ||
| Ensure that all legal definitions have been clearly communicated and acknowledged by the respective party. These may cover liability issues through to access requirements for disabled visitors. | ||
| License acquirement | ||
| Risk Management | ||
| Change Management | ||
| Handover to Maintenance Mode | ||
| Total Project Management |
Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.