Practice Known Questions
Stay up to date with your due questions
Complete 5 questions to enable practice
Exams
Exam: Test your skills
Test your skills in exam mode
Learn New Questions
Popular in this course
Learn with flashcards
Manual Mode [BETA]
Select your own question and answer types
Other available modes
Complete the sentence
Listening & SpellingSpelling: Type what you hear
multiple choiceMultiple choice mode
SpeakingAnswer with voice
Speaking & ListeningPractice pronunciation
TypingTyping only mode
ingegneria del software - Leaderboard
ingegneria del software - Details
Levels:
Questions:
311 questions
| 🇮🇹 | 🇮🇹 |
| (foss) Quali sono le immagini proposte da Eric Steven Raymond? | In queste due immagini si cerca di rappresentare i mondi foss e closed source: - la cattedrale (closed source): si tratta di un ambiente molto gerarchizzato, fortemente legato al progetto iniziale di un unico “architetto” responsabile dei lavori; - il bazaar (open source): è l’ambiente più anarchico possibile, in cui ognuno lavora per sé e costruisce espandendo ciò che gli altri hanno già fatto. Entrambe le costruzioni risultano splendide e attraenti, ma sono chiaramente legate a modi di pensare la costruzione e la progettazione totalmente opposti. |
| Quale e' la differenza in documentazione fra i vari modelli? | Tradizionale: la documentazione e' enfatizzata come sinonimo di qualita' e buon controllo agile: la documentazione e' poco enfatizzata open source: tutti gli artefatti dei developer sono disponibili incluse statistiche e documentazione |
| Quali sono i vari elementi ingegnerirstici di cui si compone un progetto? | 1) Target: ci si prefigge un obiettivo da raggiungere. 2) Metric: una metrica per misurare la qualità del software (quanto si avvicina al target). 3) Method, Process, Tool: metodi, processi e strumenti provati per avvicinarsi all’obiettivo. 4)) Measurements: vengono valutate le strategie implementate. A seconda dei risultati : - risultati soddisfacenti - accettati come buoni metodi utilizzati. - risultati insoddisfacenti - bisogna modificare il lavoro qualcosa: target o metrica oppure bisogna rivedere i processi e metodi usati. |
| In ambito di un approccio ingegneristico nella costruzione di un software, che cosa si intende per target , di che tipi può essere? | Per target generalmente si intende l'obiettivo che ci si propone all'inizio del progetto, questo può essere di due tipi: - la risoluzione dei problemi nella progettazione del software - il raggiungimento di una qualche qualità che il software dovrà avere |
| Che tipi di qualità può avere un progetto? di che tipo possono essere? | Le qualità definiscono proprietà desiderabili del prodotto, queste possono essere: qualità esterne: vengono colte dal cliente qualità interne: colte dallo sviluppatore (es requisiti o specifiche) |
| Quale è la differenza fra requisiti e specifiche? | - I requisiti sono quello che il cliente vuole che il software faccia. Spesso sono cambiati in corso d’opera oppure sono espressi in modo sbagliato, per cui è necessaria un’interazione continua. - Le specifiche sono ciò che è stato formalizzato dal programmatore a partire dai requisiti: si tratta di una definizione più rigorosa di che cosa dovrà fare il software. Si noti però che se i requisiti sono stati espressi in modo non corretto anche le specifiche risulteranno inesatte |
| Quali sono le varie qualità che un software deve avere per "funzionare"? | - Correttezza: Un software è corretto se soddisfa la specifica dei suoi requisiti funzionali. proprietà generalmente dimostrabile in modo formale. - Affidabilità: Un software è affidabile quando ci si può aspettare che faccia ciò che gli è stato chiesto. l'affidabilità è relativa: un software può essere affidabile anche quando contiene qualche errore. - Robustezza: Un software è robusto se si comporta in modo accettabile anche in circostanze non previste nella specifica dei requisiti. |
| Quali sono i vari modi in cui un software può "essere bello"? | - Usabilità: se i suoi utenti lo ritengono facile da utilizzare. generalmente viene verificato con dei test a campione. - Prestazioni ed Efficienza: -- L'efficienza è una qualità interna e misura come il software utilizza le risorse del computer; -- la performance è una qualità esterna basata sui requisiti dell'utente, ha effetto sull'usabilità e viene verificata alla fine del processo. - Verificabilità: se le proprietà correttezza e performance sono verificabili facilmente. La verifica può essere fatta con metodi formali o informali ed è considerata una qualità interna, ma alcune volte può diventare una qualità esterna: per esempio, in ambiti in cui la sicurezza è critica il cliente può chiedere la verificabilità di certe proprietà. |
| Quali sono i vari modi in cui un software può "farmi diventare ricco"? | - Riusabilità: Le componenti del software che costruiamo dovrebbero essere il più riutilizzabili possibile: ciò può essere fatto non legandole troppo allo specifico contesto applicativo del software. - Manutenibilità: Per manutenzione software si intendono tutte le modifiche apportate al software dopo il rilascio iniziale. Questa proprietà può essere vista come due : --> Riparabilità: un software è riparabile se i suoi difetti possono essere corretti con una quantità di lavoro ragionevole. --> Evolvibilità: indica la capacità del software di poter evolvere aggiugendo funzionalità. È importante considerare questo aspetto fin dall'inizio. l'evolvibilità decresce con il passare delle release |
| Che cosa dice la prima legge di R. Glass? | La mancanza di requisiti è la prima causa del fallimento di un progetto. |
| Che cosa prevede la qualità di robustezza di un progetto? | Un processo deve poter resistere agli imprevisti, come la mancanza improvvisa di personale o il cambiamento delle specifiche. Esistono certificazioni (CMM: Capability Maturity Model) che valutano la robustezza di alcuni processi aziendali e che vengono per esempio considerate nei bandi pubblici. |
| Cosa dice la legge di Nielsen- Norman? | L’usabilità è misurabile. |
| La qualità di produttività di un progetto è misurabile? | La produttività di un team è molto meno della somma della produttività individuale dei suoi componenti. È una metrica difficile da misurare: conteggi come il numero di linee codice scritte o la quantità di tempo-uomo richiesta per un lavoro si rivelano spesso un po' fallaci (per esempio, la gravidanza umana non è un'attività parallelizzabile, ma si potrebbe dire che servono 9 mesi-donna per creare un bambino). |
| Cosa dice la legge di McIlroy | Riutilizzare il software permette di incrementare la produttività e la qualità. |
| Che cosa prevede la qualità di tempismo di un progetto? | Un processo deve consegnare il prodotto nei tempi stabiliti, in modo da rispettare i tempi del mercato. È spesso conveniente la tecnica dello sviluppo incrementale, ovvero la consegna frequente di parti sempre più grandi del prodotto (es. compilatore ADA): essa permette infatti di conquistare il cliente ancor prima di avere il prodotto finito. |
| Cosa dicono le leggi di Leggi di M. Lehman ? | Un sistema che viene utilizzato cambierà. Un sistema che evolve incrementa la sua complessita a meno che non si lavori appositamente per ridurla. |
| Quali sono le varie fasi di sviluppo di un software? | 1) Studio di fattibilità 2) Analisi e specifica dei requisiti 3) Progettazione (design) 4) Programmazione e test di unità 5) Integrazione e test di sistema 6) Consegna, installazione e manutenzione 7) Attività ausiliarie |
| Che cosa prevede la fase di studio di fattibilità? | Questa fase viene svolta prima ancora che il processo di sviluppo inizi. L’obiettivo è quello di produrre un documento in linguaggio naturale presentante diversi scenari di sviluppo con soluzioni alternative, con una discussione sui trade-off in termini di benefici e costi attesi in particolare: > studio dei diversi scenari di realizzazione (architetture e hardware necessari, sviluppare in casa o subappaltare) > stima dei costi, dei tempi e delle risorse necessarie |
| Che cosa prevede la fase di analisi e specifica dei requisiti? | Fatta dopo la fase di studio di fattibilità, il suo obiettivo è la stesura di un documento di specifica in specifico prevede le fasi di : > comprensione del dominio applicativo del prodotto (dialogazione con il cliente) > identificazione degli stakeholders e dei loro interessi > identificazione delle funzionalità richieste (o specifiche) > stabilire un dizionario comune tra cliente e sviluppatore > definizione di eventuali qualità del prodotto |
| Che cosa prevede la fase di progettazione? | Prevede la strutturazione del progetto sotto diversi livelli di dettaglio attraverso un documento di specifica del progetto fasi : > scelta di una architettura e software di riferimento > scomposizione in moduli o oggetti per la spartizione dei compiti > identificazione dei pattern: ovvero problemi comuni che hanno spiriti di risoluzione simili nel corso del progetto |
| Che cosa dice l'ipotesi di Bauer-Zemane? | Metodi formali riducono in maniera significativa gli errori di progettazione, oppure permettono di eliminarli e risolverli prima. |
| Che cosa prevede la fase di programmazione e test di unità? | Vengono realizzati i moduli definiti nella fase di progettazione e vengono scritti tutti i test necessari per dimostrarne la correttezza. i moduli sono testati individualmente e eventuali dipendenze esterne vengono risolte con moduli stub che emulano le funzionalità mancanti i moduli driver hanno il compito di utilizzare il modulo che si sta testando come se fossero esterni |
| Che cosa prevede la fase di integrazione e test del sistema? | I moduli singolarmente implementati e testati vengono integrati insieme a formare il software finito (nel modello incrementale questa fase è incorporata nella fase di programmazione) vengono effettuati dei test di integrazione che verificano la buona integrazione dei vari moduli (sostituendo quelli stub) infine si fa l'alpha testing con condizioni realistiche |
| Che cosa prevede la fase di consegna, installazione e manutenzione? | > beta testing con un gruppo di utenti con lo scopo di raccogliere feedback > installazione di eventuali componenti aggiuntivi (come periferiche di rete o altre) > la manutenzione può essere definita come l’insieme delle attività finalizzate a modificare il sistema dopo essere stato consegnato al cliente: -- correttiva : correzione di errori -- adattiva : adattare il software a nuovi requisiti -- perfettiva : modificare aspetti ma non le funzionalità |
| Quali sono altre attività aggiuntive alla progettazione? | > la documentazione : è una fase trasversale viene spesso tralasciata per il frequente cambio dei requisiti o specifiche > verifica del controllo qualità: nella maggior parte dei casi, la verifica è svolta attraverso review e ispezioni. L’obiettivo è anticipare il prima possibile la scoperta e la sistemazione degli errori in modo da evitare di consegnare sistemi difettosi > Gestione del processo: gestione incentivi (premi di produzione), responsabilità, formazione del personale, perfezionamento del processo con l’esperienza guadagnata... > Gestione delle configurazioni: magari la modifica di componenti già posseduti in house |
| Che cosa dice la legge di David e in che ambito viene usata? | Usata nell'ambito della analisi e specifica dei requisiti afferma che : Il valore dei modelli che rappresentano il software da diversi punti di vista dipendono dal punto di vista preso (assunto), ma non c’è nessuna vista che è la migliore per ogni scopo. |
| Che cosa prevedono i modelli sequenziali? | I vari passaggi vengono posti in un ordine prestabilito e vengono attraversati uno alla volta uno dopo l’altro. il più famoso è il modello a cascata ogni step produce un output chiamato semilavorato che è anche l'input dello step successivo per questo questi modelli vengono chiamati anche document-based: tra una fase e l’altra si crea infatti un documento che è il mezzo di trasmissione dell’informazione |
| Quali sono le varie fasi previste nel modello a cascata? | 1) analisi dei Requisiti 2) Progettazione 3) Codifica 4) Testing 5) consegna del Prodotto |
| Quali sono i difetti dei modelli sequenziali? | 1) non prevede una fase di manutenzione e non prevede di tornare indietro in alcun modo 2) congelamento dei sottoprodotti: una volta prodotto un semilavorato esso è fisso e non può essere modificato; questo è particolarmente critico per le stime e specifiche fatte durante le prime fasi, che sono fisiologicamente le più incerte. 3) monoliticità: tutta la pianificazione è orientata ad un singolo rilascio, e l’eventuale manutenzione può essere fatta solo sul codice |
| In che cosa consiste il modello a V? | È una variante del modello a cascata che introduce una più estesa fase di testing essenzialmente introduce un interfacciamento ciclico con il cliente o con del testi per ogni fase di progettazione |
| In che cosa consistono i modelli iterativi? | Consistono nel poter tornare indietro di uno o più passaggi fra i vari step di creazione del prodotto |
| Modello a cascata con singola retroazione | Modello iterativo che consente di poter tornare ciclicamente indietro di una fase di produzione, ma una volta che il prodotto viene consegnato non è possibile applicargli alcuna modifica o miglioramento |
| Modello a fontana | Modello di tipo incrementeale. consente in qualsiasi momento di poter tornare alla fase iniziale consentendo di poter risolvere errori con un margine di operatività più profondo. dopo la consegna esistono due strade: - evoluzione - manutenzione i tempi di consegna si allungano notevolmente ma il software non è provvisto di errori dovuti al rattoppamento temporaneo |
| Che cosa prevedono i modelli incrementali? | Come il software iterativo ma fra le varie fasi sono previste fasi di consegna la manutenzione del software non è quindi più vista come una particolarità ma come una normale fase di evoluzione |
| Modello prototipale | Lo scopo non è quello di consegnare un prodotto finito ma di ricevere dei feedback per questo vengono introdotti i prototipi che possono essere: pubblici: per capire i requisiti del cliente privati: per esplorare nuovi strumenti o scelte di risoluzione dei problemi bisogna stare attenti a non consegnare prototipi come prodotti che potrebbe dare problemi di manutenibilità |
| Che cosa dice la legge di Bohem a proposito dei prototipi? | La propotipizzazione riduce gli errori di analisi dei requisiti e di design, specialmente per le interfacce utente. |
| Quali sono i difetti dei modelli incrementali? | - Lavoro di planning più complicato per la pianificazione di tutte le iterazioni - iterazioni troppo lunghe come tempo - troppe iterazioni (generano overhead) - Overlapping fra le iterazioni |
| Modelli trasformazionali | Puntano a controllare tutti i passaggi e i procedimenti in modo formale partendo da requisiti scritti in linguaggio formale si pensa di poter, tramite dei passi o trasformazioni dimostrabili, di poter generare codice corretto Questo modello ha un grande difetto ovvero le assunzioni iniziali devono essere studiate molto accuratamente per non produrre errori successivamente |
| Metodo a spirale | L'attenzione è posta prevalentemente sui rischi, perciò lo studio di fattibilità viene fatto ogni volta che si inizia una nuova iterazione. questo aiuta in particolar modo a valutare un lavoro basato su un certo budget |
| Variante della spirale win win | È una variante del metodo a spirale Ad ogni iterazione bisogna dunque trovare con esso un punto di equilibrio win-win in entrambi le parti “vincono” (o hanno l’illusione di aver vinto), così da far convergere tutti su un obiettivo comune. |
| Modello COTS | Basato sulla riusabilità del codice (ovvero di moduli già presenti sul mercato) richiede alcune attività diverse oltre alle solite - Analisi dei requisiti + Analisi dei componenti: prima di progettare considero la disponibilità di componenti che implementano una parte o tutte le funzionalità richieste; + Modifica dei requisiti: stabilisco se il cliente è disposto ad accettare un cambiamento nei requisiti necessario per utilizzare un componente particolare; + Progetto del sistema col riuso di componenti: occorre progettare il sistema per far interagire componenti che non necessariamente sono stati originariamente progettati per interagire; - Sviluppo e integrazione; - Verifica del sistema. |
| Quali sono i punti fissi delle metodologie agili? | Le metodologie agili danno maggiore enfasi alla programmazione rispetto agli altri aspetti, punti focali sono : - Gli individui e la collaborazione tra individui è più importante di processi e strumenti. - Il software che funziona è più importante della documentazione ben fatta. - La collaborazione con il cliente è più importante del contratto. - Rispondere al cambiamento è più importante che seguire un piano. |
| Kanban | Fa parte delle metodologie agile Nasce con lo scopo di minimizzare il lavoro in corso, concentrandosi per ogni momento su una singola cosa, questo perchè si ha particolare difficoltà nel context switching per gli umani le varie fasi sono : - backlog: richieste dal cliente - da fare: attività da fare in questa iterazione - in esecuzione - in testing - fatto |
| Scrum | Ha l'obiettivo del fissare dei requisiti per ogni singola iterazione (che dura 2- 4 settimane) questo per porre meno stress ai lavoratori per il cambio dei requisiti o obiettivi. |
| Crystal | Introduce il concetto di comunicazione osmotica ovvero il codice e la responsabilità di quest'ultimo appartiene al team e non al singolo, quindi la conoscenza deve essere nota a tutti i componenti - metodologia che funziona con team piccoli |
| EXtreme programming | Si fonda sui principi: - incrementa e poi semplifica (migliorando le proprietà interne del codice) - sviluppo guidato dal test (test driven development) le fasi principali sono : rosso: viene scritto un test di cose non ancora implementate verde: il test viene fatto passare il più velocemente possibile verde: refractoring e riorganizzazione del codice |
| Quali sono i vantaggi del test driven development | - facilità nel scrivere del codice facilmente testabile (dato che vengono scritti prima i test del codice) - facilità nella scrittura delle interfacce e nella definizione della loro interazione |
| Quali sono i principi dell extreme programming? | - Separazione degli interessi (aspects o concerns): separare tempi, responsabilità e moduli, ovvero tutte le varie viste o le varie dimensioni su cui si deve affrontare il problema. - Astrazione e modularità: bisogna usare le giuste astrazioni che ci permettono di dominare i problemi complessi (possono essere i diversi linguaggi di programmazione, linguaggi di descrizione o vari altri costrutti). - Anticipazione del cambiamento (design for change): in fase di progettazione il programmatore deve pensare a come potrebbe cambiare il prodotto, accomodando la possibile aggiunta di requisiti che il cliente magari non aveva neanche pensato; bisogna stare attenti però, perché spesso questo concetto complica arbitrariamente la progettazione e lo sviluppo, rischiando di far perdere molto tempo su cose che al cliente potrebbero non servire: può essere un’idea migliore partire da qualcosa di semplice ed incrementare man mano. - Generalità: per rendere più semplice la modifica e l’espansione futura è necessario scrivere interfacce molto generali ai sistemi che costruiamo. - Incrementalità: lo sviluppo avviene incrementalmente, un pezzetto alla volta. - Rigore e formalità: è importante essere rigidi e specifici sia nella comunicazione che nella descrizione dei requisiti. |
| Quali sono i principi aggiuntivi dell'eXtreme programming? | Feedback rapido: bisogna mantenere un costante flusso di feedback; questo viene dato dai test, dai colleghi ma anche dal cliente, che dev’essere continuamente consultato sullo stato dei lavori. Tra le iniziative che favoriscono un veloce ciclo di feedback c’è lo standup meeting, una riunione mattutina fatta in piedi in cui ciascuno descrive in poche parole cosa ha fatto il giorno precedente e cosa intende fare oggi. Presumere la semplicità: non bisogna complicare senza motivo né il codice, che dev’essere scritto con in mente ciò che serve a breve termine e non in un futuro remoto, né le relazioni tra colleghi, che non devono essere eccessivamente gerarchiche (tutti dovrebbero avere compiti molto simili); in generale si dovrebbe semplificare il più possibile in tutti gli ambiti del progetto. Accettare il cambiamento: non ci si deve aspettare che il software sia immutabile; al contrario, deve essere dato per scontato il concetto di flessibilità e malleabilità, ovvero che il cliente vorrà fare cambiamenti sia dopo che durante lo sviluppo del prodotto. Modifica incrementale: ritornando al concetto di baby steps, ogni iterazione di sviluppo dovrebbe essere breve e le funzionalità introdotte piuttosto piccole; questa regola si applica tuttavia a tutti gli ambiti del progetto, tra cui la gestione del team: ovvero non bisognerebbe mai aggiungere più di una persona alla volta al gruppo di lavoro, in quanto aggiungerne di più potrebbe portare a passare più tempo ad istruirle che a sviluppare. Lavoro di qualità: bisogna ovviamente ottenere un buon prodotto, ma per fare ciò la prospettiva cambia in favore dello sviluppatore, al quale si deve garantire un ambiente di lavoro salutare e un certo benessere; la fidelizzazione dei programmatori è importante perché più si trovano bene e meglio lavorano. |
| Che cosa è il lean software? dove nasce? | Nasce dall'ambiente automobilistico della ditta toyota che riesce a ottimizzare i tempi di produzione producendo in serie in casa e riducendo al minimo gli sprechi vantaggi: - scoperta degli errori molto presto - velocizzazione della produzione |
| Su quale principio si fonda il test driven development? | È una tecnica di progettazione del software che mira a far emergere “dal basso” il design più semplice in grado di risolvere un dato problema. Non si tratta piuttosto un approccio alla scrittura di questi ultimi. si fonda su due concetti fondamentali: - test first - baby steps mira a stabilire un ciclo di feedback istantaneo e evitare di perdere tempo su una soluzione che non funziona |
| Che cosa è l'extreme programming? | È una delle metodologie agili segue perciò il manifesto per lo sviluppo agile di software si fonda su due principi: - incrementa quindi semplifica - sviluppo guidato dal test |
| Quali sono i vantaggi che porta il test driven development? | Scrivere il test prima e il codice dopo aiuta invece a progettare prodotti la cui correttezza può essere provata. Scrivere prima i test aiuta a definire chiaramente le interfacce del programma e come queste comunicano tra di loro, mentre se non dovessimo farlo potremmo avere delle dipendenze complicate da rimuovere. |
| Quali sono le variabili in gioco in un progetto secondo Beck? | Portata: la quantità di funzionalità da implementare, può cambiare nel corso dello sviluppo; tempo: che si può dedicare al progetto; qualità: che si vuole ottenere, principalmente relativa a correttezza e affidabilità. si cerca di avere la qualità migliore possibile a scanso di compromessi costo: le risorse (finanziare o in termini di personale) che si possono impegnare. |
| Quali vantaggi porta al cliente uno sviluppo TDD? | Il cliente è certo che lo sviluppatore si sia dedicando al progetto siccome vede il prodotto crescere a poco a poco, inoltre anche il cliente fa parte del team, di conseguenza può accertarsi in prima persona che il team di sviluppo si dedichi al massimo delle possibilità al progetto. Dà la possibilità al cliente di avere comunque qualcosa in mano se ad un certo punto vuole interrompere la collaborazione. Permette al cliente di cambiare idea sulla portata e sulle funzionalità richieste in corso d’opera, bandendo la rigidità dei documenti di specifica. |
| Quali sono le metodologie utilizzate dall'extreme programming? | Planning game Brevi cicli di rilascio Uso di una metafora Presumere la semplicità Testing Refactoring Pair programming Proprietà collettiva Integrazione continua Settimana da 40 ore Cliente sul posto Standard di codifica They’re just rules |
| Di che cosa tratta il planning game? | È l’attività di pianificazione che viene fatta all’inizio di ogni iterazione e serve per “congelare” il sottoinsieme di requisiti sul quale il team lavorerà per le prossime ~2 settimane. 1) il client scrive le user stories 2) i developer assegnano una stima del tempo necessario per ogni US 3) il manager decide quali US implementare in questo ciclo di sviluppo |
| Come sono definite le user stories? | - numero identificativo - il soggetto, ovvero il ruolo dell’utente nell’azienda (può anche essere esterno); - l’azione che vuole eseguire il soggetto; - la motivazione che spinge il soggetto a portare avanti l’azione descritta. - un caso di test per l'accettazione - il valore che il cliente attribuisce alla user story |
| Che cosa si intende per velocity nel mondo agile? | È il numero di story point guadagnati nell’arco dell’iterazione corrente, proprio per questo motivo è poco oggettiva e molto variabile in base alle stime proposte. le storie non compiute al 100% non vengono considerate come fatte! |
| Che cosa è il team estimation game? | È un metodo di stima del lavoro nello sviluppo software che si basa su confronti tra task anziché su stime numeriche. Esso è suddiviso in tre fasi: - a turno i developer posizionano una story a destra o a sinistra di una story oppure sotto - vengono attribuiti dei valori del planning poker per ogni colonna a partire dalla prima ! - viene stimato il tempo di risoluzione di una delle prime carte, il resto delle carte viene stimato di conseguenza |
| Quali sono le problematiche principali riguardanti il team in un progetto open source? | - come comunicare - come tenersi uniti - come coordinarsi - come ottenere nuove collaborazioni |
| Come si risolve il problema della comunicazione in FOSS | Per comunicare si utilizza di solito internet: si potrebbe dire che senza internet non potrebbe esistere il concetto stesso di open source. In particolare si utilizzano spesso dei forum per organizzare il lavoro, in modo da tenere la community unita e rispondere dubbi ai nuovi utenti. |
| Uno dei problemi principali per la sincronizzazione in un progetto FOSS? | Deve poi essere facile, poter compilare il codice e ricreare l’ambiente di sviluppo omogeneo per tutti; si utilizzano quindi strumenti di build automation in modo che chiunque voglia partecipare possa farlo indipendentemente dalla propria configurazione software e hardware. |
| Come si gestiscono le nuove collaborazioni in un progetto FOSS? come vengono gestite le segnalazioni di bug? | Il software configuration management utilizzato è decentralizzato di tipo cvs. È infine importante educare i reporter dei bug e avere un sistema per organizzare per le segnalazioni di errori: il sistema dovrebbe essere accessibile a tutti in modo da evitare segnalazioni duplicate e consentire una facile organizzazione delle stesse. |
| Che cosa si intende per Software Configuration Management? | Il Software Configuration Management è l’insieme di pratiche che hanno l’obiettivo di rendere sistematico il processo di sviluppo, tenendo traccia dei cambiamenti in modo che il prodotto sia in ogni instante in uno stato (configurazione) ben definito. |
| Il mondo open source preferisce un approccio decentralizzato al version control. Perché? | - è possibile lavorare offline; - è molto più veloce, perché la rete non fa più da bottleneck; - supporta diversi modi di lavorare: --> simil centralizzato: un repository viene considerato “di riferimento”; --> due peer che collaborano direttamente; --> gerarchico a più livelli (kernel Linux). |
| Quali sono i soggetti del versioning ? | Gli “oggetti” di cui si controlla l’evoluzione sono detti configuration item o manufatti; generalmente sono file. Se si cambia nome a un file è come eliminarne uno e partire da zero con uno nuovo. Originariamente i tool tracciavano i file indipendentemente, senza un senso logico (una configurazione) comune. |
| Quali modelli di accesso esistono per un repository con accesso concorrenziale? | - modello ‘pessimistico’ (RCS): prevedo il possibile conflitto assicurandomi che chi lavora sia l’unico con l’accesso in scrittura. Funziona solo in ambienti centralizzati, nell’open source non può funzionare. - modello ‘ottimistico’ (CVS): il sistema si disinteressa del problema e fornisce supporto per le attività di merge di change-set paralleli potenzialmente conflittuali. |
| Quali sono i principali branch di gitflow? | Branch master; branch develop; feature branches; release branches; hotfix branches. |
| A che cosa serve il branch master? | Master: contiene le versioni stabili del codice sorgente, pronte per essere consegnate o rilasciate al cliente o al pubblico. Queste versioni sono considerate affidabili e testate, quindi possono essere utilizzate in produzione; |
| A che cosa serve il branch develop? | Develop: è il ramo di integrazione in cui vengono integrati i contribuiti di tutti i gruppi; è anche il punto di partenza degli altri tipi di branch. |
| A che cosa serve il branch feature? | I feature branch sono branch temporanei utilizzati per sviluppare nuove funzionalità o per correggere bug. Possono essere creati solo a partire dal branch develop e vengono utilizzati per isolare il lavoro su una specifica funzionalità o problema dal resto del codice. Quando il lavoro è completato, il feature branch viene integrato di nuovo nel develop tramite un merge |
| Come risolve git normalmente i conflitti nel merge fra due branch di cui uno e la diretta evoluzione del secondo ? | Facendo un fast forward del secondo rendendolo uguale al primo |
| Che cosa e' lo squashing? | Usando git è anche possibile eseguire in fase di merge lo squashing dei commit, ovvero la fusione di tutti i commit del branch entrante in uno solo. Questa operazione è utile per migliorare la leggibilità della history dei commit su branch grossi |
| Che cosa e' una hotfix? | Un hotfix è una riparazione veloce di difetti urgenti senza dover aspettare la prossima release. È l’unico caso per cui non si parte da develop, ma dall’ultima - o una particolare - versione rilasciata su master. |
| Quali sono alcuni difetti di git e gitflow? | La mancanza di un sistema di autorizzazione granulare, ovvero la possibilità di assegnare permessi in modo specifico e mirato a diverse funzionalità o risorse. Inoltre, non esiste una distinzione tra diversi livelli di accesso, quindi o si ha accesso completo a tutte le funzionalità o non si ha accesso a niente; l’assenza di code review, ovvero il processo di revisione del codice sorgente da parte di altri sviluppatori prima che venga integrato nel codice base. |
| Che cosa e' l'hosting centralizzato? | Hosting centralizzato Git è un servizio che fornisce una repository centrale per i progetti Git dove i contributi vengono integrati e gestiti, garantendo una maggiore trasparenza e controllo del processo di sviluppo e mantenendo molti vantaggi della decentralizzazione, come la possibilità di lavorare in modo asincrono e autonomo. esempi possono essere github e gitlab |
| Che cosa e' gerrit? | E' uno strumento di review del codice utilizzato internamente da google basato sul concetto di “peer review”: tutti gli sviluppatori sono autorizzati a fare review delle proposte di modifica di qualsiasi zona di codice. |
| Che cosa e' il verifier? | Il verifier è uno strumento o un processo che viene utilizzato in Gerrit per verificare che le modifiche proposte siano corrette e funzionino come dovrebbero. In particolare, il verifier scarica la patch, la compila, esegue i test e controlla che ci siano tutte le funzioni necessarie. Se il verifier rileva dei problemi, può segnalarli al team di sviluppo perché vengano corretti prima che la patch venga accettata. |
| Che cosa e' un approover? | Viene utilizzato da gerrit dopo il verifier per stabilire se la proposta risponde a certe domande quali: - è valida per lo scopo del progetto? - è valida per l’architettura del progetto? - introduce nuove falle nel design che potrebbero causare problemi in futuro? - segue le best practices stabilite dal progetto? - è un buon modo per implementare la propria funzione? - introduce rischi per la sicurezza o la stabilità? |
| Che cosa e' il build automation? | La build automation è un processo fondamentale nello sviluppo di software open source, che consiste nel creare un sistema automatizzato per compilare il codice sorgente in un eseguibile. strumenti utilizzati nella build automation sono: - make - Ant - Gradle |
| Che cosa e' make? | Make è uno strumento di build automation che viene utilizzato per automatizzare il processo di compilazione di un progetto. make segue la filosofia pipeline, ovvero prevede l’utilizzo di singoli comandi semplici concatenati per svolgere compiti più complessi. |
| Che cosa e' Ant? | E' un sistema per la build automation ideato da Apache che utilizza una descrizione XML del progetto e delle sue dipendenze per la compilazione del progetto. Il vantaggio è che Java offre un livello d’astrazione sufficiente a rendere il sistema di build portabile su tutte le piattaforme. |
| Che cosa e' Gradle? | Gradle è uno strumento di build automation che utilizza le repository Maven come punto di accesso alle librerie di terze parti. Maven è una piattaforma di gestione delle dipendenze e della build automation per il linguaggio di programmazione Java. Le repository Maven sono archivi online che contengono librerie Java, plugin e altri componenti utilizzati nella build di progetti Java. Gradle utilizza queste repository per cercare e scaricare le librerie di cui ha bisogno per eseguire la build del progetto. oltre a maven si possono utilizzare anche Groovy e Kotlin |
| A che cosa servono i plugin nella build automation ? un esempio? | I plugin servono per trattare tool, situazioni, linguaggi definendo task e regole per lavorare più facilmente. Il plugin Java definisce: una serie di sourceSet, ovvero dove è presente il codice e le risorse. Principalmente sono: - src/main/java: sorgenti Java di produzione; - src/main/resources: risorse di produzione; - src/test/java: sorgenti Java di test; - src/test/resources: risorse di test. dei task, anche con dipendenze tra loro. |
| Quali sono gli obiettivi del bug tracking? | L’obiettivo del bug tracking è avere più informazioni possibili su ogni bug per saperli riprodurre e quindi arrivare a una soluzione. |
| Che cosa sono gli issue? | Un issue è un problema o una richiesta di funzionalità segnalata all’interno di un progetto di software. Gli issue vengono solitamente utilizzati per tenere traccia dei problemi noti o delle richieste di nuove funzionalità all’interno di un progetto, e possono essere gestiti attraverso un sistema di bug tracking o gestione delle richieste. Gli issue possono essere aperti da qualsiasi membro del team o dalla comunità, e possono essere risolti o chiusi da un membro del team responsabile. |
| In quali modi puo' essere risolta la segnalazione di un bug? | - duplicate: quando è stato già segnalato in precedenza e quindi non rappresenta un problema nuovo. In questo caso, viene solitamente fatto riferimento al numero del bug originale che ha già ricevuto una risoluzione; - wontfix: il bug viene chiuso come “non risolvibile” perché o rappresenta una funzionalità voluta dal progetto o è troppo complesso da risolvere per essere considerato conveniente farlo dal punto di vista dei progettisti; - can’t reproduce: non è stato possibile riprodurre il bug, ovvero che non è stato possibile ottenere lo stesso risultato o il comportamento segnalato dal bug. Ciò può essere dovuto a una mancanza di dettagli o a un errore nella segnalazione del bug stesso; - fixed: il bug è stato fixato; vs fix verified: il fix è stato integrato in una release passando tutti gli step di verifica. |
| Quali sono le regole da rispettare durante il refactoring? | Le modifiche al codice non devono modificare le funzionalità: il refactoring DEVE essere invisibile al cliente; non possono essere aggiunti test aggiuntivi rispetto alla fase verde appena raggiunta. |
| Quali possono essere i motivi che spingono al refactoring? | - design complesso e poco leggibile - design che non si integra bene con feature successive. In questo caso, se il refactoring non è banale è bene fermarsi, tornare indietro e evolvere il codice (design for change). - presenza di debolezze e “scorciatoie” che ostacolano notevolmente evoluzioni future: “ogni debito tecnico lo si ripaga con gli interessi”. - migliorare l'efficienza del codice |
| Sotto che forme si puo' presentare il design knolwledge di un progetto? | - Memoria: memoria individuale del programmatore, soggetta a variazioni e dimenticanze... - Documenti di design (linguaggio naturale o diagrammi): se non viene aggiornato di pari passo con il codice rimane obsoleto, risultando più dannoso che d’aiuto. - Piattaforme di discussione (version control, issue management): le informazioni sono sparse in luoghi diversi e difficili da reperire , le informazioni necessitano di manutenzione. - gli UML: tramite diagrammi UML si è cercato di sfruttare l’approccio generative programming, ovvero la generazione automatica del codice a partire da specificazioni di diagrammi. (non funziona) - nel Codice : tramite la lettura del codice è possibile capire il design ma è difficile rappresentare le ragioni della scelta. |
| In quali modi puo' essere condiviso il know how? | - metodi: con pratiche (come Agile) o addirittura l’object orientation stessa, che può essere un metodo astratto per condividere scelte di design. - design pattern: fondamentali per condividere scelte di design, sono utili anche per generare un vocabolario comune (sfruttiamo dei nomi riconosciuti da tutti per descrivere i ruoli dei componenti) e aiutano l’implementazione (i pattern hanno delle metodologie note per essere implementati). I pattern non si concentrano sulle prestazioni di un particolare sistema ma sulla generalità e la riusabilità di soluzioni a problemi comuni; - principi: per esempio i principi SOLID. |
| Quali sono le proprieta' dell'object orientation? | - ereditarietà: ovvero la possibilità di poter definire una classe ereditando proprietà e comportamenti di un’altra classe. - polimorfismo: quando una classe può assumere diverse forme in base alle interfacce che implementa. - collegamento dinamico: in Java il tipo concreto degli oggetti e quindi il problema di stabilire quale metodo chiamare viene risolto durante l’esecuzione. es: Forma quadrato = new Quadrato(5); quadrato.calcolaArea(); non chiama il metodo in forma ma il metodo in quadrato! |
| Quali sono i principi SOLID? | SINGLE RESPONSIBILITY: una classe, un solo scopo. Così facendo, le classi rimangono semplici e si agevola la riusabilità. OPEN-CLOSE PRINCIPLE: le classi devono essere aperte ai cambiamenti (opened) ma senza modificare le parti già consegnate e in produzione (closed). Il refactoring è comunque possibile, ma deve essere preferibile estendere la classe attuale. LISKOV SUBSTITUTION PRINCIPLE: c’è la garanzia che le caratteristiche eredidate dalla classe padre continuinino ad esistere nelle classi figlie. Questo concetto si collega all’aspetto contract-based del metodo Agile: le precondizioni di un metodo di una classe figlia devono essere ugualmente o meno restrittive del metodo della classe padre. Al contrario, le postcondizioni di un metodo della classe figlia non possono garantire più di quello che garantiva il metodo nella classe padre. Fare casting bypassa queste regole. INTERFACE SEGREGATION: più le capacità e competenze di una classe sono frammentate in tante interfacce più è facile utilizzarla in contesti differenti. In questo modo un client non dipende da metodi che non usa. Meglio quindi avere tante interfacce specifiche e piccole (composte da pochi metodi), piuttosto che poche, grandi e generali. DEPENDENCY INVERSION: il codice dal quale una classe dipende non deve essere più concreto di tale classe. Per esempio, se il telaio della FIAT 500 dipende da uno specifico motore, è possibile utilizzarlo solo per quel specifico motore. Se invece il telaio dipende da un concetto di motore, non c’è questa limitazione. In conlusione, le classi concrete devono tendenzialmente dipendere da classi astratte e non da altre classi concrete. |
| Che cosa afferma la Legge di Parnas? | Solo ciò che è nascosto può essere cambiato liberamente e senza pericoli. |
| Quali principi deve rispettare una classe per essere immutabile? | Una classe si dice immutabile quando il suo stato non puo' essere modificato dopo la sua creazione : - non fornire metodi di modifica allo stato; - avere tutti gli attributi privati per i tipi potenzialmente mutabili (come List<T>); - avere tutti gli attributi final se non già privati; - assicurare l’accesso esclusivo a tutte le parti non mutabili, ovvero non avere reference escaping. |