[APPUNTI DI INFORMATICA] - L'Analisi del Progetto 3/3

[APPUNTI DI INFORMATICA] - L'Analisi del Progetto 3/3 postato il 21/03/2016 17:41:35 nel forum programmazione, gdrcd, open source, hosting

Abbiamo dunque sottolineato la scelta di utilizzare il codice libero: che si provveda a sviluppare il progetto in proprio o con l'aiuto di terzi, vi è l'ultima fase prima di iniziare veramente con i lavori, quella cosidetta del "mockup".

Nell'ingegneria del software (ed in generale) il mockup non è altro che una visione di presentazione, la cosiddetta "demo", di quel che sarà il progetto finito e delle sue funzionalità richieste, eventuali personalizzazioni e tutto ciò che il progetto deve comprendere. Questo tipo di passo richiede, per forza di cose, un approccio top-down allo sviluppo del progetto, cosicchè globalmente vi sia una chiara visione di cosa si voglia, dove si voglia andare a parare e vi sia anche una possibile definizione dei compiti ed ambiti di ogni membro appartenente al progetto.

Come abbiamo visto in precedenza, la creazione di uno screenshot per un modulo come può essere la chat, permette di dare allo sviluppatore la chiara idea su cosa il gestore voglia: colore della chat, sfondi, colore delle scritte, posizione degli elementi e loro contenuti. Essendo questo uno screenshot, ovviamente non possono essere presenti automazioni visibili, quindi sarà necessario descrivere in ogni sottolivello del progetto, tutto ciò che deve risultare dinamico o essere modificabile dall'utente. A volte questo sistema viene anche definito con l'acronimo DMU (Digital MockUp).

Il mockup del progetto, quindi, si comporrà di alcuni screenshot che richiameranno l'idea globale del progetto (land). Nel mockup è ovviamente possibile e prevedibile lasciare alcuni punti "oscuri" perchè non ancora chiari da parte del gestore o per eventuali modifiche successive (es: "li ci sarà la barra presenti, poi vedremo in un secondo tempo come farla perchè ci sto pensando ancora"). L'importante è che vi sia una idea chiara di cosa si voglia ottenere: nulla rende lo sviluppo ed il rapporto con lo sviluppatore più frustrante, come il dover scrivere e rifare più volte lo stesso codice a seguito di continui cambi d'idea.

Nella fase del mockup è fondamentale l'intervento dello sviluppatore, così che possa a sua volta suggerire soluzioni o migliorìe al progetto frutto della propria esperienza. Come detto prima: se riuscite a spiegarlo e soprattutto renderlo graficamente, vuol dire che si può fare. Partite dal presupposto che il "lavoro difficile" di adattamento deve essere sempre e solo da parte di chi sviluppa il codice, in quanto è esso che produce il risultato finale.

Immaginate, per esempio, quali e quante righe di codice vi siano dietro la semplice somma su excel quando vi trovate a scrivere =A1+C4 : il risultato è semplice, banale quasi ma anche senza basi di informatica è chiaro che vi siano parecchi passaggi dal riconoscimento del carattere "=", alla ricerca e validazione del valore in A1, la ricerca e validazione del valore in C4, la verifica di compatibilità del formato, la somma, eccetera...

Tonando al mockup: non vi è un modo univoco di crearlo, nè un modo unico e giusto di farlo in quanto il pensiero umano è davvero complicato e complesso. Posso suggerirvi di usare una struttura a grafo o albero, ovvero un insieme di quadrati o cerchi che rappresentano ogni "vista" (gli screenshot che avete creato) legati da freccie direzionali, in modo da poter seguire un percorso ed avere chiaramente in mente quali siano le operazioni fattibili dall'utente standard.

Nota bene: il progetto va sempre, almeno all'inizio, pensato solo ed esclusivamente per l'utente standard ovvero il livello di accesso usuale di ogni giocatore; solo in un secondo tempo si procederà a complicare il mockup con le funzioni dedicate ai gruppi ristretti di utenti (master, capocorporazione, fato, destiny, admin, mod, etc...). Questo permette di avere una base solida sulla quale lavorare e poter intervenire avendo già spazi e percorsi definiti.

Per determinati elementi, soprattutto quando il gestore non ha le idee ben chiare, è possibile prediligere un approccio bottom-up confidando sull'esperienza dello sviluppatore e mettendo insieme i vari moduli così che assumano una visione globale. Fate attenzione, in questo caso, a non lasciare scoperti ambiti e funzionalità. Riprendendo l'esempio precedente della lista presenti, lo sviluppatore potrebbe rispondere con "ho già un modulo fatto per conto mio, guarda se ti piace" così da modificarlo in base alle esigenze.


Se siete arrivati a leggere fino a questo punto, avrete notato che già molte delle cose descritte sono normale procedura per la creazione di una land e che, magari inconsapevolmente nei termini, erano già attuate ed applicate.
Avere un mockup pronto ed usare la corretta definizione, permette di ridurre i tempi e riuscire ad ottenere il massimo da voi o da chi vi aiuta a sviluppare il vostro progetto, in quanto ogni cosa è definita e pronta all'uso.

quota

21/03/2016 20:40:19

Utilissimi consigli per aiutare i profani a comunicare al meglio con i professionisti :D e di conseguenza aiutare loro.

Dominion Gdr ↗
In una NY con un tessuto sovrannaturale nascosto, il Bronx Vampirico e il Queens dei Lupi ribollono sotto il Dominio dei Bokor. Quanto durerà la pace?

quota

24/03/2016 11:47:54

"A volte questo sistema viene anche definito con l'acronimo DMU (Digital MockUp)." o più semplicemente solo "mockup" ahhaha

Consigli utili concordo 😎

quota