1.2 Fornire una serie di esempi (sia positivi che negativi) che indicano l’impatto del software sulla nostra società.
L’uso del software nella nostra società ha una serie di impatti sia positivi che negativi. Mentre gli aspetti positivi possono essere estremamente utili, quelli negativi ci forniscono un po ‘ di stampella. In generale, il software non è progettato per “ferirci” in alcun modo, ma piuttosto per rendere le cose più facili e più efficienti per noi.
1.3 Per esempio, E-banking è un perfetto esempio di software che rende la nostra vita molto più facile. Tutto a corto di prelevare fisicamente denaro dalla tua banca può essere fatto online. È anche possibile depositare i vostri stipendi ora semplicemente scattare una foto di esso con il tuo smartphone. Sul lato negativo, quella stessa tecnologia può essere utilizzata per rubare i numeri di carta di credito e l’identità se cade nelle mani sbagliate. Lo stesso con il software anti-sicurezza.
Ci sono persone che vengono pagate bene per hackerare la tua banca locale e rubare da loro solo per dimostrare alla banca che hanno bisogno di aggiornare la loro sicurezza di rete. Nella maggior parte dei casi, le banche sono grati per questo tipo di intrusione. Questo stesso software, tuttavia, potrebbe essere utilizzato per scopi criminali in cui la banca non sarebbe così contento. Il software può essere sia estremamente utile che estremamente pericoloso a seconda di chi lo usa e come.
1.4 Molte applicazioni moderne cambiano frequentemente-prima di essere presentate all’utente finale e poi dopo che la prima versione è stata messa in uso. Suggerisci alcuni modi per creare software per fermare il deterioramento dovuto al cambiamento.
Prima di tutto, le applicazioni software dovrebbero essere mantenibili. Il che significa che dovrebbe essere progettato in modo che le modifiche possano essere apportate piuttosto facilmente man mano che l’applicazione cresce. Un modo per ridurre al minimo il deterioramento dovuto al cambiamento è quello di consentire aggiornamenti automatici da costruire in. Prendi il sistema operativo Windows per esempio: ha la possibilità di consentire l’aggiornamento automatico per le piattaforme di sicurezza e firewall necessarie per garantire che il sistema sia sempre “aggiornato.”Poiché le applicazioni precedenti vengono sempre aggiornate, è importante creare nuovo software con le stesse funzionalità.
1.5 Considerare le sette categorie di software presentate nella Sezione 1.1.2. Pensi che lo stesso approccio all’ingegneria del software possa essere applicato per ciascuno? Spiega la tua risposta.
Milioni di ingegneri del software in tutto il mondo sono al lavoro su progetti software in una o più di queste categorie. In alcuni casi, vengono costruiti nuovi sistemi, ma in molti altri, le applicazioni esistenti vengono corrette, adattate e migliorate. Per questo motivo, un approccio diverso all’ingegneria del software può essere richiesto per le singole categorie. Molti dei programmi su cui lavorano gli ingegneri del software sono estremamente vecchi e continuano ad essere aggiornati. Pertanto, ha senso che non useresti lo stesso approccio per un programma esistente che useresti per un nuovo programma.
1.6 La figura 1.3 pone i tre livelli di ingegneria del software sopra un livello intitolato “un focus sulla qualità.”Ciò implica un programma di qualità organizzativa come la gestione della qualità totale. Fai un po ‘ di ricerca e sviluppa uno schema dei principi chiave di un programma di gestione della qualità totale.
TQM può essere definito come la gestione di iniziative e procedure finalizzate al raggiungimento della consegna di prodotti e servizi di qualità. Una serie di principi chiave può essere identificata nella definizione di TQM, tra cui:
- Executive Management-Top management dovrebbe agire come il driver principale per TQM e creare un ambiente che garantisce il suo successo.
- Formazione-I dipendenti dovrebbero ricevere una formazione regolare sui metodi e sui concetti di qualità.
- Attenzione al cliente-I miglioramenti nella qualità dovrebbero migliorare la soddisfazione del cliente.
- Processo decisionale-Le decisioni di qualità dovrebbero essere prese in base alle misurazioni.
- Metodologia e strumenti-L’uso di metodi e strumenti appropriati garantisce che le non conformità siano identificate, misurate e rispondano in modo coerente.
- Miglioramento continuo-Le aziende dovrebbero lavorare continuamente per migliorare le procedure di produzione e qualità.
- Cultura aziendale-La cultura dell’azienda dovrebbe mirare a sviluppare la capacità dei dipendenti di lavorare insieme per migliorare la qualità.
- Coinvolgimento dei dipendenti – I dipendenti dovrebbero essere incoraggiati ad essere proattivi nell’identificare e affrontare i problemi relativi alla qualità.
1.7 L’ingegneria del software è applicabile quando vengono create le WEBAPP? In tal caso, come potrebbe essere modificato per adattarsi alle caratteristiche uniche delle Webapp?
Il software è diventato profondamente radicato praticamente in ogni aspetto della nostra vita. L’ingegneria del software è applicabile quando vengono creati nuovi programmi e quando vengono aggiornati i programmi esistenti, incluse le WEBAPP. Le WEBAPP sono una delle numerose categorie di software distinte. Eppure, si può sostenere che le WEBAPP sono diverse. Una delle principali modifiche richieste dalle WEBAPP è la disponibilità. Gli utenti di Webapp popolari spesso richiedono l’accesso su base 24/7/365. Un’altra caratteristica unica delle WEBAPP è la loro continua evoluzione.
A differenza del software applicativo convenzionale che si evolve su una serie di versioni pianificate e distanziate cronologicamente, le applicazioni Web si evolvono continuamente. Quando si tratta di ingegneria del software applicata alle WEBAPP, molte voci devono essere ascoltate. L’aspetto di una WebApp è una parte innegabile del fascino che alla fine determinerà il successo delle app.
1.8 Man mano che il software diventa più pervasivo, i rischi per il pubblico (dovuti a programmi difettosi) diventano una preoccupazione sempre più significativa. Sviluppa uno scenario apocalittico ma realistico in cui il fallimento di un programma per computer potrebbe causare gravi danni (economici o umani).
Uno dei primi scenari tragici ma realistici che viene in mente è il fallimento di programmi specifici su un aereo di linea. I principali programmi computerizzati sugli aerei hanno lo stesso rischio di fallire come qualsiasi altro programma e possono avere risultati catastrofici. Ad esempio, il sensore che rileva l’altitudine di un aeromobile consente al pilota di sapere quanti piedi l’aeromobile è sopra la terra. Questo programma è particolarmente necessario quando le condizioni meteorologiche potrebbero compromettere la visibilità della pista da parte dei piloti.
Una volta che un aereo di linea inizia la sua decente e si prepara ad atterrare, il pilota utilizza questi programmi per guidare l’aereo ad un atterraggio sicuro. Se questo programma dovesse fallire e il tempo ostacolasse la visibilità dei piloti, il pilota potrebbe non sapere quanto è lontano dal suolo. Incidenti aerei accadono tutto il tempo, e centinaia di passeggeri muoiono ogni anno – per lo più a causa di programmi falliti e strumenti sul velivolo.
1.9 Descrivi un quadro di processo con parole tue. Quando diciamo che le attività quadro sono applicabili a tutti i progetti, significa che le stesse attività di lavoro sono applicate a tutti i progetti, indipendentemente dalle dimensioni e dalla complessità? Spiegare.
Il processo di ingegneria del software non avviene magicamente senza una sorta di ordine e pianificazione organizzativa. Un framework di processo crea le basi per il processo di ingegneria utilizzando un piccolo numero di attività applicabili a tutti i progetti. L’algoritmo passo-passo per un framework di processo è composto da cinque attività: comunicazione, pianificazione, modellazione, costruzione e distribuzione. Tutti i programmi, indipendentemente dalla loro dimensione e complessità sono conformi a queste attività in quell’ordine. Sebbene i dettagli del processo software saranno molto diversi per ogni programma, le attività coinvolte nel framework rimangono le stesse.
1.10 Le attività ombrello si verificano durante tutto il processo del software. Pensi che siano applicati in modo uniforme in tutto il processo, o sono alcuni concentrati in una o più attività quadro.
In generale, le attività ombrello sono applicate in tutto un progetto software e aiutano un team di software a gestire e controllare i progressi, la qualità, il cambiamento e il rischio. Poiché il processo di ingegneria del software non è un regime rigido che deve essere seguito con precisione da un team di software, il processo ha molto spazio per l’adattamento.
Sebbene le attività ombrello che si verificano durante il processo siano generalmente applicate a tutti gli aspetti del processo, l’ingegneria dovrebbe essere agile e adattabile; specifica al problema, al progetto, al team e alla cultura organizzativa. Per questo motivo, un processo adottato per un progetto potrebbe essere significativamente diverso da un processo adottato per un altro progetto e alcune attività potrebbero essere concentrate in una o più aree.