Hai descritto quello che viene chiamato modello a cascata, che nello sviluppo software (almeno attualmente) è un po' la pecora nera usata per promuovere le altre metodologie. Attualmente vanno più di moda i metodi agili dove, piuttosto che "perdere tempo" (e.g., stima dei costi, tempi e risorse) a produrre documenti si ambisce a mettersi all'opera il prima possibile, promuovendo uno sviluppo incrementale. Nel giro di poche (e.g., 2 o 3) settimane vuoi avere qualcosa di funzionante, che non potrà mai essere quello che hai sognato fin dall'inizio, ma ti aiuta a capire cosa vuoi veramente. Poi, a scadenze periodiche (e.g., sempre ogni 2-3 settimane) ti prefiggi l'obiettivo di rilasciare la nuova versione e di ri-capire quali sono le vere priorità del progetto. Ciò che hai descritto può funzionare in alcune industrie, ma è considerato fallimentare nell'industria software: prima di ottenere qualcosa, hai sei già andato in fallimento. Anzi, anche nelle altre industrie si tende a preferire approcci più moderni (e.g., lean production).Partendo da questo punto, si divide il progetto in tappe e si approcciano una alla volta. Per quella poca "economia aziendale e gestione del progetto" che ho fatto posso dirti che strumenti utili per questa fase sono i diagrammi di Gantt (realizzabili, ad esempio, con Project) che permettono di schematizzare e costi, tempi e risorse per ogni fase. Le fasi devono essere fasi logiche, quindi si parte dalla preparazione delle risorse, calcolo dei costi, progettazione, implementazione ecc, e per ognuna potenzialmente si possono fare delle suddivizioni, es. progettazione - interfaccia, progettazione-backend e via discorrendo
Hai ragione a dire che ci sono svariati tipi di database, ma principalmente ce ne sono solo due: relazionali e nosql. In quelli relazionali prima si fa uno schema (con carta e penna) per capire di cosa si ha bisogno e come le informazioni sono legate tra loro, in quelli nosql invece si fa tutto "a caso" (senza una struttura chiaramente definita) con l'obiettivo principale di fare fast prototyping. In nessun caso si prende una struttura già pronta, ogni database è strettamente legato ai dati che sei interessato a trattare.4) In maniera puramente generale, so che ci sono svariati tipi di database, come devo interrogarmi per capire quale sia ciò di cui ho bisogno ?
2) Considerando che i dati che verrano inseriti nel DB verrano estrapolati dalla vita quotidiana ( da una analisi sulle persone fuori dall'ufficio, F2F) e inseriti successivamente nel DB, sarebbe opportuno avere una struttura (sempre che abbia senso ciò che ho appena detto) già pronta a ricevere questi i dati o ci si muove di pari passo?
Ovviamente sto semplificando molto, ma a domande vaghe non si può che rispondere in modo approssimativo.
Un po' come dire che il lavoro più complesso per un cuoco è quello di coltivare frutta e verdura e allevare gli animali. Popolare il database è sicuramente un'attività dispendiosa, ma tipicamente non è niente di difficile. Il primo step da fare è capire cosa ti interessa memorizzare e cosa no (e.g., i dati che ti interessano se vuoi fare uno shop online saranno molto diversi dai dati che ti interessano per un videogame di sport).1) Dopo aver fornito in maniera definitiva e chiara le caratteristiche chiave e gli obiettivi del software al full-stack developer e, avendo ben chiaro che al di là del programma, la parte DB sarà la più complessa per via della grande mole di dati da inserirvi (questo a mio avviso), quali sarebbero i primi step da fare per la progettazione del DB ?
Domanda veramente troppo vaga. Il tuo software online potrebbe non aver nemmeno bisogno di un database per risolvere il problema X. Il tuo database potrebbe non aver nemmeno bisogno di un (ulteriore) software per rispondere Y a una domanda (aka query). Non sta scritto da nessuna parte che ogni software (online) ha bisogno di un database.3) Ragionando a mente aperta vorrei capire se quanto segue ha un senso logico: Il mio software deve poter analizzare un problema X e restituisce un valore che successivamente sarà utilizzato per trovare Y nel DB, dove Y è il valore che risolvere X.