Problema Comprensione della definizione IEEE di Ingegneria del software

Naviga le tue risposte
2

Sfondo

L'ingegneria del software è l'applicazione di un approccio sistematico, disciplinato e quantificabile alla progettazione, allo sviluppo, al funzionamento e alla manutenzione del software e allo studio di questi approcci; cioè, l'applicazione dell'ingegneria al software.

Il mio istruttore, spiegando questa definizione, mi ha detto che i termini "sistematico", "disciplinato" e "quantificabile" implicano "uno dopo l'altro, strutturati", "ripetibili" e "misurabili" tra le varie altre interpretazioni possibili. Tuttavia, è la seconda parte della definizione che mi confonde. Quando parla di "implicazioni", l'ha descritto in questo modo: "è il processo di manutenzione del software, come l'aggiornamento o il patching di parti di esso. In precedenza abbiamo rimosso l'intero software e modificato la sorgente, ricompilandola e installarlo indietro Questa parte della definizione è più o meno di importanza storica - il modo in cui l'ingegneria è stata pensata in altre discipline come l'ingegneria meccanica. "

Domanda

Sono molto confuso su ciò che la definizione implica su SE.

  • Se "operazione" era solo il processo di manutenzione del software, perché includerlo nella definizione in modo indipendente?
  • In caso contrario, cosa implicano i termini "Operazione" e "Manutenzione" nella definizione?
  • La manutenzione e l'operazione non sono ancora in fase di sviluppo? Diciamo che stiamo sviluppando un componente di aggiornamento automatico di un software per la manutenzione, non significa che stiamo "sviluppando" anche la parte "manutenzione"? Perché includere gli altri due nella definizione allora?

Per favore, spiegami cosa significa veramente SE. Grazie!

    
posta Forbidden Overseer 15.01.2013 - 16:25
fonte

2 risposte

5

"Operazione" ha a che fare con la distribuzione, la configurazione, l'avvio / arresto e il monitoraggio del software. Ad esempio, nel mio negozio, lo sviluppo costruisce un archivio tar dell'applicazione e lo mette in una posizione specifica sul server di produzione. Un altro gruppo prende il tarball, lo espande nella directory di destinazione, imposta le credenziali Kerberos, aggiunge voci a diversi database, ecc. Abbiamo diverse utilità che controllano le applicazioni; si raccolgono statistiche, si emette un avviso se un'applicazione è andata giù, si rimbalza l'app se una connessione è stata interrotta o è necessario ottenere un nuovo ticket Kerberos, un archivio e ruota i file di registro, si cerca e identifica i file principali, ecc. C'è anche un file di configurazione che può essere aggiornato se cambia un indirizzo IP o il numero di porta, o se alcuni parametri di configurazione specifici dell'applicazione devono essere abilitati / disabilitati, ecc.

Nessuno di queste cose coinvolge toccare il codice sorgente, quindi è un'attività separata dalla manutenzione e dallo sviluppo. Tutte queste attività hanno processi e procedure definiti 1 associati ad essi.

L'ingegneria del software non riguarda la scrittura del codice. L'ingegneria del software riguarda lo sviluppo di processi e procedure che rendono l'atto di scrivere codice e in esecuzione più affidabile e ripetibile.

Modifica

La manutenzione (almeno nella mia testa) comprende tutte le attività non codificanti coinvolte nella gestione di un'applicazione nel corso della sua vita. Ciò include (ma non è limitato a) la gestione dei report di difetti e incidenti, la decisione di quali difetti sono stati corretti nelle patch successive, le patch di pianificazione e di staging, ecc. Alcuni altri esempi dal mio negozio sono la migrazione di applicazioni da un server all'altro, la migrazione di un cliente da un'applicazione back-end a un'altra, eseguendo analisi del traffico e delle prestazioni e generando istanze aggiuntive per gestire il traffico aumentato o ridurre al minimo i tempi di risposta, ecc.

Sviluppo (ancora una volta, nella mia testa, le definizioni "ufficiali" possono variare) è tutto ciò che tocca il codice, sia che si scriva codice nuovo da zero o che si aggiusti il codice esistente.

1 - Processo == cosa fai, procedura == come lo fai.
risposta data 15.01.2013 - 21:28
fonte
-2

SE è principalmente BS, perché il software non è un artefatto fisico.

Le reali discipline ingegneristiche (elettriche, civili, meccaniche, chimiche) sono applicate alla scienza. Accumulano conoscenze sui limiti dei materiali e li usano per costruire sistemi sicuri ed efficaci. Stimiamo il tempo e il costo dei progetti di costruzione fisica dopo il completamento del progetto. Per i progetti nuovi, la stima è ancora inaccurata.

Lo sviluppo del software è TUTTO il design e ogni progetto è nuovo. (Altrimenti si riutilizzerebbe solo il codice esistente). Le limitazioni non sono fisiche ma psicologiche e sono altamente variabili. Non esiste un "programmatore-ora" standard. Alcuni programmatori possono risolvere problemi in ore che altri non risolveranno mai. C'è poca o nessuna differenza tra il lavoro necessario per produrre una stima e il lavoro necessario per produrre una soluzione.

Abbiamo appreso alcune tecniche per organizzare il codice che sembrano aiutare. Tuttavia, i programmatori poveri non solo non seguono quelle tecniche, non le capiscono. In questo modo "l'ingegneria del software" assomiglia alla "scienza dell'educazione" - non esiste una formula magica per la programmazione o l'insegnamento.

    
risposta data 16.06.2018 - 17:51
fonte

Leggi altre domande sui tag

Pensieri su una struttura dati personalizzata per un'implementazione nodo / catena Shift Javascript framework - Che modello è questo? MVP, MVC o qualcos'altro [chiuso]