Discussione Informazioni di base, sviluppo piattaforma online.

[Andres H]

Ciao a tutti, sono nuovo sul Forum e spero di poter ricevere supporto da persone più competenti di me in materia di sviluppo software.
In particolare ho necessità di capire a grandi linee come avviene la progettazione e lo sviluppo di un software online in modo da potermi fare le domande giuste sulle risorse e competenze di cui ho bisogno da inserire nel progetto.

Di seguito alcune domande che oltre a farVi capire il mio starter point in campo, cioè -1, spero vi diano un idea anche su come fornirmi delle linee guida.

1) Come strutturo un "Work breakdown structure" di un Software ?
2) In che modo un software viene costruito e collegato a un database da dove utilizzerà dati per la corrette iterazioni logiche ?
3) L'algoritmo: quando è il momento di svilupparlo, in che fase e in che modo si inserisce nel programma ?
4) Dove/come avviene la costruzione di un software, quali linguaggi/suit si usano?

So che c'è il rischio di esser stato tropo poco preciso, ma quello di cui necessito non èuna spiegazione tecnica, ma avere delle linee guida che mi aiutino a capire come strutturare il progetto, di che risorse e competenze ho bisogno.
Poi magari dopo un giro di domande e risposte riuscirò ad essere più chiaro.
Grazie

 

[0xbro]

Punto 0: avere ben chiaro in testa cosa si vuole andare a costruire e progettare. Bisogna avere le idee lucide sulle 5W (un po' come per gli articoli di giornale) e avere una buona visione di insieme

Come strutturo un "Work breakdown structure" di un Software ?

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

2) In che modo un software viene costruito e collegato a un database da dove utilizzerà dati per la corrette iterazioni logiche ?

Per questo punto ti consiglio di studiare gli schemi Entità-Relazione. Sostanzialmente, il database deve supportare il programma nelle sue funzionalità e ne deve mantenere i dati. La struttura è fatta seguendo la logica del programma e il linguaggio usato per interrogare il DB è solitamente l'SQL.
Come si integrano back-end e DB? Ogni linguaggio permette di usare delle funzioni che si interfacciano con il DB, ne estraggono/inseriscono i dati e ne restituiscono il risultato al programma. In genere si parte dalla progettazione del DB e si costruisce poi il programma su di esso. Punti salienti di questa fase sono le iterazioni tra le tabelle e le chiavi.

3) L'algoritmo: quando è il momento di svilupparlo, in che fase e in che modo si inserisce nel programma ?

L'ideale è partire quando il DB è pronto e quando la fase progettuale dell'interfaccia è pronta. Ovviamente bisogna aver già definito ad alto livello come il programma si dovrà comportare.
Capiterà sempre che in fase di sviluppo si dovranno apportare delle modifiche al progetto o alle strutture, è immancabile che qualcuno abbia avuto delle sviste. Lo scheletro portante però deve già essere stato definito.

4) Dove/come avviene la costruzione di un software, quali linguaggi/suit si usano?

Anche qua dipende da costi, tempo, risorse ecc. Si può far stare tutto su uno stesso server (sconsigliato!) oppure de-centralizzare le componenti e mettere DB e web-server su server differenti. Linguaggi ce ne sono molti (php, python, java...) e dipende tutto da cosa uno vuole ottenere e cosa sa fare. Non c'è una unica risposta. Anche i web server sono diversi, esiste IIS, esiste Apache e ne esistono altri

 

[Andres H]

Grazie Oxbro. Sei stato estremamente chiaro.

Non ho intenzione di dilungarmi molto su questa discussione vista la mia limitata competenza che potrebbe essere contro producente per tutte le parti coinvolte nel Forum.

Di seguito gli ultimi punti su cui vorrei ricevere un tuo riscontro, grazie.

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 ?

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?

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.

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 ?

Grazie Tante Oxbro

 

[St3ve]

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 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).

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?

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.
Ovviamente sto semplificando molto, ma a domande vaghe non si può che rispondere in modo approssimativo.

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 ?

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).

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.

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.

 

[Andres H]

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).

Stiamo parlando quindi di rilasciare un MPR di bassa qualità il prima possibile, testare e poi successivamente confermare o ridefinire le caratteristiche prima di arrivare ad un MPR di alta qualità e così via fino al prodotto finale. Così insomma il prodotto non arriva sul mercato già obsoleto o pieno di caratteristiche che nessuno vuole utilizzare.

Messaggio unito automaticamente: 8 Luglio 2020

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.

Si infatti non avevo grosse pretese vista la assoluta generalità delle domande.. ma comunque tutte le risposte molto costruttive. Mi aiuteranno.

Messaggio unito automaticamente: 8 Luglio 2020

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).

Ok chiaro St3ve. Non appena farò più chiarezza, cioè quando arriverà il mio CTO farò domande più precise (spero non c’è ne sarà bisogno..) era per avere un idea generale anche su che skills/competence devo puntare, e dalle vostre risposte mi sto facendo un idea

 

[St3ve]

Stiamo parlando quindi di rilasciare un MPR di bassa qualità il prima possibile, testare e poi successivamente confermare o ridefinire le caratteristiche prima di arrivare ad un MPR di alta qualità e così via fino al prodotto finale. Così insomma il prodotto non arriva sul mercato già obsoleto o pieno di caratteristiche che nessuno vuole utilizzare.

Nel mondo del software non esiste il prodotto finale. Se domani leggi sui giornali "IPhone 11 Pro sarà l'ultimo IPhone in produzione e 13.5 sarà l'ultima versione di iOS, non ci saranno versioni successive" tu non penserai "ah che bello, finalmente posso comprare la versione completa dell'IPhone e non avrò bisogno d'altro" bensì dirai "IPhone è morto, passo ad Android".

L'idea "moderna" (ormai è da 20 anni che se ne parla) consiste nel creare team piccoli, da 7-10 persone, dove non tutti sono sviluppatori. Una (piccola) parte del team non si occupa di sviluppare, ma si occupa di rappresentare gli stakeholders così che se io (sviluppatore) ho una domanda posso rivolgermi a te (acquirente) per capire esattamente cosa vuoi. E tu sei nel mio ufficio 8h al giorno perché fai parte del mio team.

Ti piacerebbe tirare fuori i soldi e basta, però io pretendo che tu faccia questo sacrificio così da limitare un sacco di spiacevolezze (e.g., non darti quello che vuoi veramente e non capire quali sono le vere priorità). Io mi prefiggo l'obiettivo di sfornare qualcosa di usabile entro ed ogni 2-3 settimane. Dopo che ti consegno quella mini-versione, ci ritroviamo (tutto il mio team + tutti gli stakeholders) per metterci d'accordo su funzionalità aggiungere nella prossima mini-release che rilascerò tra 2-3 settimane. Ovviamente, in così poco tempo, nessuno può pretendere la luna, io posso rifiutarmi di darti la feature richiesta e posso chiederti di spezzarla in features più semplici così da consegnartela nei tempi prefissati (che sono fissi per tutto il progetto). Durante quelle 2-3 settimane nessuno può cambiare idea su quali sono i goal per la prossima mini-release.

Ad esempio, Firefox rilascia una versione ogni 4 settimane: non 4 per la prossima, poi 12 per quella dopo, poi solo 1 per quella dopo ancora, poi 18 per quella dopo ancora, ecc... cascasse il mondo, ogni 4 settimane hanno la nuova mini-release.

Se ne vuoi sapere di più a riguardo in rete c'è tantissimo materiale. È tutta roba discorsiva che non richiede alcun prerequisito per essere compresa (anche dai non-informatici).

 

[Andres H]

Ok grazie tante, sia per le pretese che per le informazioni che mi hai fornito.
Sei stato d’aiuto, grazie!