Questa pagina fornisce ulteriori dettagli per approfondire e/o completare i documenti e i principi coperti dalla Lista di controllo Gestione progetti - Best Practices.
Gli elenchi di cui alla presente sottosezione non sono esaustivi, ma sono intesi come introduzione.
Durante l'implementazione di AEM (in particolare per la prima volta) sarà necessario rivedere le funzionalità e flussi di lavoro di AEM per essere certi delle aree desiderate e necessarie.
Considerare le caratteristiche di AEM che si intende utilizzare e l'impatto sulla progettazione; ad esempio:
Inoltre, controllare le Note sulla versione, per le diverse versioni di AEM, per vedere quando sono state aggiunte nuove funzioni.
AEM può essere integrato con altri prodotti Adobe e/o servizi di terze parti. Questi possono aumentare la potenza e le funzionalità a vostra disposizione.
Per ulteriori informazioni, vedere Integrazione delle soluzioni.
Una considerazione importante è se si desidera:
Per passare da una versione precedente a quella corrente, sono disponibili due opzioni:
Come per qualsiasi progetto, è fondamentale stabilire regole di base il prima possibile. Comprendono:
Questi punti sono generici, la lista di controllo delle best practice contiene informazioni specifiche relative alle AEM.
Ruoli
Questi devono essere chiaramente definiti e resi noti a tutti coloro che partecipano al progetto. Inoltre, è opportuno evidenziare:
Responsabilità
Partecipazione
Coinvolgendo al più presto le parti interessate è possibile incoraggiarle a diventare parti interessate nel progetto, aumentando così il loro impegno per il suo successo.
Percorsi di comunicazione
Processi
I processi da definire dipenderanno dal singolo progetto. Tentate di mantenere questi semplici, tenendo conto di:
Strumenti di tracciamento
Sono disponibili molti strumenti per il tracciamento delle informazioni su bug, attività e altri aspetti del progetto. Per ulteriori informazioni, vedere Panoramica sugli strumenti potenziali.
Ambito
Definisce chiaramente i settori che devono essere coperti dal progetto a vari livelli:
Generazione rapporti
Definite chiaramente quali informazioni segnalerete, in quale forma, con quale frequenza e a chi.
Terminologia
Ipotesi
Tali informazioni possono essere definite all'interno di un manuale del progetto; l'utilizzo di un wiki può anche garantire che le modifiche in corso vengano gestite in modo efficiente. In ogni caso, i fattori chiave sono i seguenti:
Le organizzazioni utilizzano indicatori prestazioni chiave (KPI, Key Performance Indicators) per valutare il loro successo nel raggiungimento dei target. Questi indicatori sono valori misurabili che possono essere utilizzati per dimostrare l'efficacia del conseguimento di obiettivi specifici.
Questi indicatori possono essere:
Business:
Spettacolo:
Alcuni indicatori, ma non tutti, possono essere basati sulle metriche di destinazione identificate e definite.
Le metriche vengono utilizzate per definire le misurazioni quantitative per la qualità del sito Web, ovvero una definizione degli obiettivi prestazionali che si desidera raggiungere e che può essere utilizzata per definire i KPI (Key Performance Indicators).
È possibile definire molte metriche, ma spesso quelle definite coprono gli obiettivi per prestazioni e concorrenza. In particolare, fattori che possono essere difficili da quantificare e che sono spesso soggetti a valutazione emotiva:
"il nostro sito Web è troppo lento oggi" - quando lento è qualificato?
"tutto si arresta quando il mio collega effettua l'accesso" - quanti utenti simultanei possono supportare il sistema?
"quando si esegue una ricerca, il sistema si chiude in un blocco " - quali richieste di ricerca influiscono sul sistema?
"il download del file richiede ages" - quali sono i tempi di download accettabili (in condizioni di rete normali)?
Le metriche di destinazione sono definite all'inizio di un progetto per:
Quando si definiscono le metriche di destinazione, occorre sempre prestare attenzione:
Durante lo sviluppo del progetto possono essere aggiornati e sintonizzati secondo necessità. Dopo che il progetto è stato implementato correttamente, possono essere utilizzati per controllare l'installazione e monitorare/mantenere i livelli di servizio richiesti per il funzionamento in corso.
Se utilizzate correttamente, queste metriche possono fornire uno strumento utile; se usati in modo irresponsabile, possono essere una distrazione che perde tempo. Come sempre, è necessario capire cosa si sta misurando, come lo si misura e perché.
La presente sezione si occuperà dei principi e delle questioni fondamentali da esaminare. Ogni installazione è diversa, quindi i valori effettivi da misurare saranno diversi.
Tutte le metriche da misurare saranno in qualche modo influenzate dalla progettazione del progetto. Al contrario, molti problemi saranno risolti al meglio con le modifiche alla progettazione.
Pertanto, è necessario definire le metriche di destinazione prima di decidere in merito alla progettazione. Questo consente di ottimizzare la progettazione in base a questi fattori. Una volta sviluppato il progetto, sarà difficile apportare modifiche ai principi di progettazione di base.
Quando create la struttura per il sito Web, seguite la struttura consigliata per AEM siti Web. Assicuratevi di comprendere i seguenti problemi e/o principi:
Se ritenete che la progettazione non segua le linee guida, o se non siete sicuri di alcune delle implicazioni, chiarite questi problemi prima di iniziare la fase di programmazione o riempire il contenuto.
Per definire o valutare l'infrastruttura, sarà utile definire valori target quali:
A seconda della situazione e del significato strategico del sito Web, questo vi aiuterà a valutare e scegliere l'infrastruttura:
Esistono diversi fattori di prestazione che possono essere valutati:
tempi di risposta per le singole pagine, tenendo conto:
tempi di risposta per le richieste di ricerca
Questa sezione può essere letta insieme a Performance Optimization che amplia i dettagli tecnici della misurazione effettiva delle prestazioni.
Un problema chiave è rappresentato dal tempo impiegato dal sito Web per rispondere alle richieste dei visitatori.
Anche se questo valore varia per ogni richiesta, è possibile definire un valore target medio. Una volta dimostrato che questo valore è sia raggiungibile che gestibile, può essere utilizzato per monitorare le prestazioni del sito web e indicare lo sviluppo di potenziali problemi
Oggetti diversi negli ambienti di creazione e pubblicazione
I tempi di risposta desiderati saranno diversi negli ambienti di creazione e pubblicazione, in base al pubblico di destinazione:
Ambiente di authoring
Questo ambiente viene utilizzato dagli autori che immettono e aggiornano il contenuto, pertanto deve:
Ambiente di pubblicazione
Questo ambiente contiene il contenuto che potete rendere disponibile agli utenti:
la velocità è ancora vitale, ma è spesso più lenta rispetto all’ambiente di authoring
vengono spesso applicati ulteriori meccanismi di miglioramento delle prestazioni:
Come si può decidere sui tempi di risposta raggiungibili (medi)? Spesso si tratta di una questione di esperienza:
Tuttavia, in circostanze controllate, si possono applicare le seguenti linee guida:
I numeri sopra riportati si basano sulle seguenti condizioni:
Sono disponibili diversi meccanismi per monitorare i tempi di risposta:
Monitoraggio dei tempi di risposta con AEM request.log
Un buon punto di partenza per l'analisi delle prestazioni è il registro delle richieste. Tra le altre informazioni, potete utilizzarlo per visualizzare i tempi di risposta delle singole richieste. Per ulteriori informazioni, vedere Ottimizzazione delle prestazioni.
Monitoraggio dei tempi di risposta con commenti 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
Le richieste di ricerca possono avere un impatto significativo sul sito Web, in termini di:
Tempo di risposta della ricerca effettiva
Impatto sulle prestazioni generali
L'impostazione dei target per le richieste di ricerca è, ancora una volta, una questione di esperienza a seconda:
Questi devono essere pianificati e integrati fin dall'inizio del progetto. I meccanismi disponibili per il monitoraggio comprendono:
Monitoraggio dei tempi di risposta della ricerca con AEM request.log
Anche in questo caso, request.log può essere utilizzato per monitorare i tempi di risposta per le richieste di ricerca; per ulteriori informazioni, vedere Ottimizzazione delle prestazioni.
Meccanismi programmati per misurare i tempi di risposta delle ricerche
Per personalizzare le informazioni raccolte sulle richieste di ricerca e le relative prestazioni, si consiglia di includere la raccolta di informazioni nel codice sorgente del progetto; per ulteriori informazioni, vedere Ottimizzazione delle prestazioni.
Il sito Web verrà reso disponibile a diversi utenti/visitatori, sia nell’ambiente di creazione che nell’ambiente di pubblicazione. I numeri sono spesso più numerosi di quelli utilizzati per i test, ma anche fluttuanti e difficili da prevedere. Il sito Web dovrà essere progettato per un numero medio di utenti/visitatori simultanei, senza che si noti un impatto negativo sulle prestazioni. Anche in questo caso, la request.log
può essere utilizzata per effettuare test di concorrenza; per ulteriori informazioni, vedere Ottimizzazione delle prestazioni.
Le destinazioni per il numero di utenti simultanei dipendono dal tipo di ambiente:
Ambiente di authoring
Ambiente di pubblicazione
Prima di discutere delle metriche correlate, una rapida definizione dei termini:
Volume
Capacità
Capacità e volume
What / Where | Capacità | Volume |
---|---|---|
Client | Potenza computazionale del computer dell'utente. | Complessità del layout della pagina. |
Rete | Larghezza di banda della rete. | Dimensioni della pagina (codice, immagini e così via). |
Cache del dispatcher | Memoria server del server Web (memoria principale e disco rigido). | Server Web (memoria principale e disco rigido). Numero e dimensione delle pagine memorizzate nella cache. |
Cache di output | Memoria server del server AEM (memoria principale e disco rigido). | Numero e dimensione delle pagine nella cache di output, numero di dipendenze per pagina. La cache del dispatcher riduce questo volume. |
Server web | Potenza computazionale del server Web. | Quantità di richieste. La cache abbassa questo volume. |
Modello | Potenza computazionale del server Web. | Complessità dei modelli. |
Archivio | Prestazioni del repository. | Numero di pagine caricate dalla directory archivio. |
Le sezioni precedenti descrivono le metriche principali da definire.
A seconda dei requisiti specifici, potrebbe essere utile definire metriche aggiuntive, isolatamente o tenendo conto delle classificazioni di cui sopra.
Tuttavia, è preferibile disporre di un set limitato di metriche di base precise che funzionino in modo facile e affidabile, anziché cercare di misurare e definire ogni aspetto del sito Web. Per sua stessa natura, il tuo sito web inizierà a cambiare ed evolvere non appena viene consegnato ai tuoi utenti.
La sicurezza è fondamentale e una sfida in continua crescita. deve essere considerato e pianificato fin dalle prime fasi del progetto.
La lista di controllo di sicurezza procedura dettagliata da eseguire per garantire che l'installazione AEM sia sicura quando distribuita. Altri aspetti di sicurezza sono trattati in Sicurezza (durante lo sviluppo) e Amministrazione utente e sicurezza.
Seguono:
Per una nuova implementazione di un progetto AEM standard è necessario considerare attività quali:
Per tutti gli aspetti si raccomanda di utilizzare un approccio iterativo:
Suddividere il lancio del progetto in Lanci morbidi (disponibilità ridotta, iterazioni multiple) e Lancio rigido (disponibilità completa - Dal vivo) per consentire l'ottimizzazione, l'ottimizzazione e la formazione degli utenti in condizioni realistiche nell'ambiente di produzione.
Per esempi di attività da eseguire (o valutare) durante il ciclo di vita del progetto, vedere Project Checklist.
Alcuni punti da sottolineare per ciascuna categoria sono:
Sviluppo
Definire innanzitutto l'architettura di base.
Utilizzare diverse iterazioni (sprint) per lo sviluppo:
Pianificare l'eventuale aggiornamento della versione AEM disponibile durante il progetto.
Pianificare i test e l'ottimizzazione durante gli spruzzi.
Pianificare le fasi di stabilizzazione e ottimizzazione.
Crea un registro di elementi da pianificare per ulteriori rilasci.
Pianificare il coinvolgimento e la consegna dei partner.
Infrastruttura
Definire innanzitutto l'architettura di base:
Utilizzare diverse iterazioni; per la prima fase di preparazione e la configurazione iniziale:
Pianificare diversi test di carico.
Pianificare i test e l'ottimizzazione durante gli spruzzi.
Pianificare una fase di stabilizzazione e ottimizzazione.
Implementare l'ambiente di produzione il prima possibile (lasciare che il team operativo configuri il sistema per acquisire esperienza).
Utilizzate gli utenti denominati e i ruoli definiti il prima possibile.
Pianificare la formazione (ad esempio, formazione di amministratore).
Piano per il passaggio alle operazioni.
Contenuto
A seconda dell'elenco di attività risultante, è quindi possibile effettuare stime iniziali del tempo e del lavoro necessari per le definizioni di attività (di alto livello). Devono includere un'indicazione di chi (cliente o partner) farà cosa e quando.
L'elenco seguente mostra approssimazioni standard e interrelazioni di sforzo, e quindi costi:
Tali cifre possono essere utilizzate solo per le stime iniziali. Uno sviluppatore AEM esperto deve eseguire un'analisi dettagliata.
Fase | Sforzo |
---|---|
Sviluppo | Una stima approssimativa di 2-4 ore per ciascun nodo di componente coprirà tutti i requisiti di sviluppo. |
Test per sviluppatori | 15% di sviluppo |
Seguito | 10% di sviluppo |
Documentazione | 15% di sviluppo |
Documentazione JavaDoc | 10% di sviluppo |
Correzione dei bug | 15% di sviluppo |
Gestione progetto | 20% dei costi del progetto per la gestione e la governance dei progetti in corso |
Una pianificazione dettagliata può quindi collegare le risorse disponibili o necessarie a scadenze e costi.
L'architettura di riferimento è data per fornire una soluzione modello per l'architettura AEM. L'architettura di riferimento risolve i problemi più comuni riscontrati per i sistemi aziendali, tra cui il ridimensionamento, l'affidabilità e la sicurezza.
È necessario definire le metriche del sito seguenti:
Classificazione | Definizione |
---|---|
Numero di siti Internet | |
Numero di siti Intranet | |
Numero di basi di codice (ad esempio se Internet e Intranet sono diversi) | |
Numero di singole pagine | |
Numero di visite al sito / giorno | |
Numero di visualizzazioni pagina/giorno | |
Volume (in GB) di trasferimento dati/giorno | |
Numero di utenti simultanei (gruppo utenti chiuso) | |
Numero di visitatori simultanei (pubblicazione) | |
Numero di autori simultanei | |
Numero di autori registrati | |
Numero di attivazioni di pagina/giorno lavorativo | |
Numero di attivazioni di pagina durante la distribuzione |
Viene fornito l’elenco seguente per informarvi sugli strumenti che possono essere utilizzati. Si tratta di un'introduzione, non di un elenco esteso di raccomandazioni, e certamente non dovrebbe dissuadervi dall'utilizzare altri strumenti che preferite.
Prodotto | Descrizione |
AEM | AEM fornisce una serie di meccanismi che consentono di monitorare, testare, esaminare ed eseguire il debug dell'applicazione; compresi: |
Selenio | Seleniumis uno strumento di test Open Source. I test vengono eseguiti direttamente nel browser, emulando il funzionamento degli utenti. |
Microsoft Project | Uno strumento di gestione del progetto di uso comune. |
Jira | Jirais uno strumento Open Source per tenere traccia e gestire i dettagli dei bug software. I flussi di lavoro possono essere imposti sui dettagli del bug come richiesto. |
Git | Gite un software di controllo revisione. |
Eclipse | Eclipse è un IDE open source, composto da vari progetti. Si tratta della creazione di una piattaforma di sviluppo aperta, composta da framework estensibili, strumenti e tempi di esecuzione per la creazione, l'implementazione e la gestione del software nel corso del ciclo di vita. Per ulteriori informazioni, vedere Come sviluppare AEM progetti con Eclipse. |
IntelliJ | Un IDE professionale (e quindi soggetto a costi di licenza) che offre una vasta gamma di funzioni. Per ulteriori informazioni, vedere Come sviluppare AEM progetti con IntelliJ IDEA. |
Paradiso | Mavenis è uno strumento di gestione e comprensione del progetto software che può gestire il processo di creazione di un progetto (software e documentazione). |
Inoltre, sono di particolare interesse le seguenti sezioni:
Adobe offre ulteriori Best practice per tutte le fasi e per il pubblico: