come automatizzi più requisiti di report che sono complessi?

Question

come automatizzi più requisiti di report che sono complessi?

#1 da (7 voti)
#2 da (3 voti)

2

Mi è stato assegnato il compito di automatizzare i report utilizzati da più team. Ogni team ha una propria procedura su come generare il report che è necessario fornire.

Posso automatizzare i report ma ci vuole così tanto tempo da quando ho bisogno di studiare ciascuna delle loro procedure e poi testarle.

Il problema si verifica quando un team deve aggiornare una procedura. Se eseguirò tale rettifica, potrebbe essere necessaria una settimana per distribuirla sul server live che non è accettabile per il cliente.

Quello che penso è creare interfacce per gli utenti in modo che possano configurare i propri report, ma la quantità di complessità che devono essere considerati è troppo. Sarebbe bello se i requisiti di una squadra fossero semplicemente filtrare field1 con questo valore e field2 con questo ma no. Fanno tutti i tipi di cose come la fusione dei valori, l'applicazione delle condizioni, ecc. È un passo in più per ogni squadra e non tutti i team hanno gli stessi passaggi.

Lo strumento più vicino che posso usare è il generatore di rapporti di django. Ma può soddisfare solo i requisiti fino a un certo punto.

programming-practices complexity reporting report-generation

posta niccolo m. 22.11.2017 - 12:47

fonte

2 risposte

3

A seconda di quanto diversi siano i tuoi team e qual è il coraggio del tuo obiettivo, un approccio da considerare è:

Fornire una o due soluzioni di reporting comuni ai progetti e lasciare che i progetti con requisiti più specifici o divergenti creino le proprie soluzioni.
Implementare una o due soluzioni di reporting comuni come microservizi, in modo che siano indipendenti da molti elementi specifici del progetto, forse anche indipendenti dalle origini dati del progetto. Ad esempio, un'API che si aspetta come parametri i dati del report e le istruzioni (formato di output, modello, destinazione, ecc.) Significa che ogni progetto che chiama l'API può ottenere i dati richiesti, ma è necessario trasformarli per la chiamata API.

Speriamo che questo ti dia un altro modo di pensare al problema.

risposta data 29.11.2017 - 10:22

fonte

Leggi altre domande sui tag programming-practices complexity reporting report-generation

Programmazione funzionale: l'uso di un generico rende impura una funzione? Refactoring progetto di C ++ legacy basato su codice di grandi dimensioni che si è mescolato con lo stile C

score 7 · Accepted Answer

La trasformazione programmatica dei fogli di Excel non è la strada da percorrere. Esaminerò completamente l'intera procedura e utilizzerò un database come origine dati per i rapporti.

O consentire agli utenti di inserire i dati di origine direttamente nel database tramite un'applicazione appropriata o di importare i dati di Excel nel database (in un processo automatizzato).

Una volta che i dati sono nel database, puoi inserire i dati nella forma corretta utilizzando le query del database. Questo è molto più semplice di manipolare le celle in un foglio Excel a livello di programmazione. In base a queste query è possibile creare report utilizzando un generatore di report (commerciale). I generatori di report moderni possono creare report in vari formati tra cui un'anteprima dello schermo, PDF, HTML, RTF e persino Excel.

Vai lontano da questo bricolage di Excel.

Uno dei principali svantaggi di Excel è che i dati non hanno una struttura predefinita. Gli utenti possono inserire i dati in qualsiasi modo desiderano da altamente organizzati a completamente caotici. Ciò rende estremamente difficile elaborarlo a livello di codice. D'altra parte, un database ha tabelle predefinite con colonne predefinite, tipi di colonne predefiniti e relazioni predefinite tra le tabelle, il che rende molto più facile l'implementazione degli automatismi, poiché si ha una solida base su cui lavorare. Mentre i fogli di Excel possono essere distribuiti tra diversi file system e cartelle e possono avere nomi casuali, un database si trova di solito in un posto centrale e unico e accessibile attraverso una stringa di connessione predefinita.

I fogli di Excel possono essere molto sofisticati, ma non sono scalabili. Sto sviluppando software professionalmente. Molti dei miei progetti di database (incluse le applicazioni come front-end) sono iniziati con i fogli Excel che ho ricevuto dai clienti. Erano molto abili nella creazione di fogli complessi. Ma raggiunsero un punto in cui il foglio diventava troppo complesso e difficilmente poteva evolversi ulteriormente. Il problema principale è che i set di dati complessi contengono quasi sempre relazioni da 1 a n e questi possono solo essere riprodotti molto male in un foglio di calcolo. Un foglio di calcolo è fondamentalmente adatto solo per dati flat. Inoltre, la presentazione e la struttura sono le stesse in Excel. Ma spesso hai bisogno di diverse valutazioni e presentazioni degli stessi dati. Ecco dove entrano in gioco i database (back-end) con un'applicazione appropriata (front-end) e i generatori di report.