Come tenere traccia del crescente catalogo delle regole aziendali?

Question

Come tenere traccia del crescente catalogo delle regole aziendali?

#1 da (6 voti)
#2 da (-1 voti)

4

Costruendo la mia ultima applicazione, tutti hanno iniziato a perdere il controllo sulla crescente complessità delle regole aziendali, che sarebbero state aggiunte ogni settimana, soprattutto i proprietari delle app stesse. Alla fine, abbiamo dovuto spiegare loro il comportamento della loro app, perché hanno dimenticato quello che avevano definito alcune settimane prima.

Con la mia app attuale, vedo avvicinarsi una situazione simile; nella loro attività quotidiana, i proprietari delle app affrontano problemi con singoli client che di solito convertono in una regola aziendale, ad esempio: se il client corrente è xy, utilizza un modello di notifica diverso.

Abbiamo provato a usare Lucidcharts per creare una sorta di diagramma o wireframe per tenere traccia di ciò che l'app dovrebbe effettivamente fare. Contrassegnerei una regola nel wireframe con un ID, ovvero # 01, quindi riferirò quell'ID al codice effettivo. Ma è difficile coinvolgere tutti, specialmente le persone non tecnologiche (imprenditori).

Quale sarebbe il formato per mantenere un catalogo organizzato di regole aziendali, come riferimento per il programmatore, il project manager e il proprietario dell'attività commerciale?

E se qualcuno ha voglia di votare questa domanda, ti preghiamo di spiegarne il motivo.

complexity business-logic

posta Michael 05.10.2018 - 18:59

fonte

2 risposte

Leggi altre domande sui tag complexity business-logic

Programmazione di sistema e progettazione orientata agli oggetti - cosa cercare [chiuso] che dovrebbe spostare lo stato dello sprint per completare il modello di mischia agile

score 6 · Answer 1

I requisiti devono essere documentati. Stai già tentando di farlo, ma i requisiti sono spesso suddivisi in una serie di categorie:

Requisiti aziendali : elementi come "Un post di blog richiede un titolo" sarebbe considerato un requisito aziendale.
Requisiti funzionali : spiegano in dettaglio come si comporta l'applicazione. Il gergo tecnico inizia a comparire: "Se il campo del titolo del post del blog è vuoto, visualizza questo messaggio di convalida:" Il titolo è un campo obbligatorio "
Requisiti tecnici - Fresco di gergo tecnico, sono quasi incomprensibili per il business: "Utilizza il metodo RuleFor (...) in FluentValidation per contrassegnare la proprietà PostTitle" not empty " nel modello di visualizzazione BlogPostForm

Ci sono molti strumenti là fuori che si specializzano nell'organizzazione dei requisiti, ma le raccomandazioni sugli strumenti sono fuori tema per questo sito.

Oltre i requisiti, una metodologia di sviluppo chiamata Sviluppo guidato dal comportamento (BDD) (utilizzando Gherkin language ) essenzialmente consente di scrivere test di accettazione degli utenti in un formato in linguaggio naturale e utilizzando i binding in un linguaggio di programmazione, questi test diventano test di funzionamento reali che può interagire con un'interfaccia utente e un database reali.

Un vantaggio di BDD è che i requisiti aziendali diventano test che passano o falliscono man mano che l'applicazione si evolve. Per far passare i test, è necessario aggiornare le regole aziendali. Affinché l'applicazione mantenga l'applicazione di regole aziendali nuove o modificate, è necessario aggiornare l'applicazione dopo aver riscritto le regole. Ti costringe a mantenere aggiornata la documentazione, perché hai dei test falliti.

score -1 · Answer 2

Separa la creazione di regole dalla distribuzione di aggiornamenti al software.

Se disponi di molte regole aziendali che appartengono alla varietà if-then , puoi prendere in considerazione l'utilizzo di un Motore per le regole aziendali , che consente di fornire un'interfaccia per la gestione delle regole, eseguita dai proprietari dei prodotti e un'API per l'esecuzione e l'applicazione delle regole, che viene eseguita dal software (e dagli sviluppatori scrivendolo).

Se le tue regole stanno crescendo e cambiano rapidamente, è probabilmente difficile per l'intero team passare attraverso l'intero ciclo di sviluppo-test-build-deploy per ogni regola. Un motore di regole aiuterà a disgiungere la creazione e la "distribuzione" delle regole dalla distribuzione degli aggiornamenti al software.

Ad esempio, un motore di regole open-source per Java è Drools.

link

Questo sarebbe un costo iniziale maggiore rispetto all'utilizzo di un framework BDD o di regole di documentazione con un linguaggio in stile BDD, poiché implica la configurazione di un sistema in esecuzione per gestire l'authoring delle regole, ma il vantaggio è che le modifiche alle regole possono arrivare alla produzione molto più veloce rispetto a BDD. Potrebbe essere o meno appropriato per il volume di regole del tuo software, ma se le regole cambiano più velocemente di quanto il software possa cambiare , questa è un'opzione da discutere con il tuo team.