* Un controllo � formalizzato �di un walkthrough�, tipicamente con 3-8 genti compreso un moderatore, il lettore e un registratore prendere le note. L'argomento di controllo � tipicamente un documento quali spec. di requisiti o un programma di prova e lo scopo � di trovare i problemi e vedere che cosa manca, per non riparare nulla. I membri dovrebbero prepararsi per questo tipo di venire a contatto leggendo attraverso il documento; la maggior parte dei problemi saranno trovati durante questa preparazione. Il risultato della riunione di controllo dovrebbe essere un rapporto scritto.
i generi 10.What di prova dovrebbero essere considerati?
* Scatola nera che esamina - non basata su qualsiasi conoscenza del disegno o del codice interno. Le prove sono basate sui requisiti e sulla funzionalit�.
* Scatola bianca che esamina - basata su conoscenza della logica interna del codice dell'applicazione. Le prove sono basate su riempimento delle dichiarazione di codice, rami, percorsi, circostanze.
* Prova dell'unit� - la scala �pi� micro� di prova; per esaminare le funzioni particolari o i moduli di codice. Fatto tipicamente dal programmatore e non dai tester, come richiede la conoscenza dettagliata del disegno e del codice interni di programma. Fatto non sempre facilmente a meno che l'applicazione abbia un'architettura ben progettata con il codice stretto; pu� richiedere i moduli del driver della prova o i cablaggi svilupparsi della prova.
* Integrazione incrementale che esamina - la prova continua di un'applicazione come nuova funzionalit� � aggiunta; richiede che le varie funzioni di funzionalit� dell'applicazione sono abbastanza indipendenti funzionare esclusivamente prima che tutte le parti del programma siano completate, o che i driver della prova sono sviluppati come stati necessari; fatto dai programmatori o dai tester.
* Prova di integrazione - prova delle parti unite di un'applicazione per determinare se funzionano insieme correttamente. �Le parti� possono essere moduli di codice, diverse applicazioni, applicazioni dell'assistente e del cliente su una rete, ecc. Questo tipo di prova � particolarmente relativo al cliente/assistente ed ai sistemi distribuiti.
* Prova funzionale - il tipo esaminare della nero-scatola ha adattato ai requisiti funzionali di un'applicazione; questo tipo di prova dovrebbe essere fatto dai tester. Ci� non significa che i programmatori non dovrebbero controllare che il loro codice funzioni prima di liberarla (che naturalmente si applica a tutta la fase di prova.)
* Prova del sistema - tipo esaminare della nero-scatola che � basato sulle liste dei requisiti generali; riguarda tutte le parti unite di un sistema.
* Prova faccia a faccia - simile alla prova del sistema; l'estremit� �a macroistruzione� della scala della prova; coinvolge la prova di un ambiente completo di applicazione in una situazione che imita l'uso nell'ambiente, come interazione con una base di dati, usando le comunicazioni della rete, o l'interazione con altri fissaggi, applicazioni, o sistemi se adatto.
* Sanity che esamina o prova del fumo - tipicamente uno sforzo difficile iniziale determinare se una nuova versione di software sta effettuando abbastanza bene per accettarla per uno sforzo difficile importante. Per esempio, se il nuovo software sta arrestando i sistemi ogni 5 minuti, sta impantanandosi i sistemi ad un crawl, o sta corrompendo le basi di dati, il software non pu� essere �in un sensato� abbastanza circostanza per garantire pi� ulteriormente la prova nella relativa corrente dichiara.
* Prova di regressione - riprovando dopo le difficolt� o le modifiche del software o del relativo ambiente. Pu� essere difficile da determinare quanto riprovare � necessario, particolarmente vicino all'estremit� del ciclo di sviluppo. Gli attrezzi difficili automatizzati possono essere particolarmente utili per questo tipo di prova.
* Prova di accettazione - prova finale basata sulle specifiche dell'utilizzatore finale o del cliente, o basata su uso dagli utilizzatori finali/clienti per un certo periodo limitato di tempo.
* Prova del carico - verificando un'applicazione sotto i carichi pesanti, come prova di un Web site sotto una gamma di carichi per determinare a che punto il tempo di reazione del sistema degrada o viene a mancare.
* Prova di sforzo - termine usato spesso scambievolmente con �il carico� e �le prestazioni� che esaminano. Inoltre ha usato descrivere tali prove come la prova funzionale di sistema mentre sotto i carichi insolitamente pesanti, la ripetizione pesante di determinati azioni o input, l'input di grandi valori numerici, le grandi domande del complesso ad un sistema della base di dati, ecc.
* Prova di prestazioni - chiamare scambievolmente usato spesso con �lo sforzo� e �il carico� che esamina. �Le prestazioni� esaminare (e qualunque altro �tipo� di prova) sono definite Nel migliore dei casi nella documentazione di requisiti o nel QA o nei programmi di prova.
* Prova di impiego possibile - esaminando �a facilit� d'uso per l'utente�. Questo � chiaramente soggettivo e dipender� dall'utilizzatore finale o dal cliente designato. Le interviste dell'utente, le indagini, la video registrazione delle sessioni dell'utente ed altre tecniche possono essere usate. I programmatori ed i tester non sono solitamente adatti come tester di impiego possibile.
* Installare/esaminare del uninstall - la prova di in pieno, parziale, o l'aggiornamento installa/processi del uninstall.
* Prova di recupero - esaminando come un sistema recupera dagli arresti, dai guasti dei fissaggi, o da altri problemi catastrofici.
* Prova di Failover - usata tipicamente scambievolmente con �la prova di recupero�
* Prova di sicurezza - esaminando come il sistema protegge da accesso interno o esterno non autorizzato, da danni ostinati, ecc; pu� richiedere le tecniche di collaudo specializzate.
* Prova di compatibilit� - esaminando come il software effettua in un ambiente particolare dei fissaggi/software/sistema operativo/rete/ecc.
* Prova esplorativa - presa spesso per significare una prova creativa e informale del software che non � basata sui programmi di prova convenzionali o sui casi della prova; i tester possono imparare il software come lo verificano.
* Prova ad-hoc - simile alla prova esplorativa, ma preso spesso per significare che i tester hanno comprensione significativa del software prima di verificarlo.
* prova Contesto-guidata - esaminare guidata da una comprensione dell'ambiente, della coltura e dell'uso progettato di software. Per esempio, il metodo difficile per il software medico vita-critico dell'apparecchiatura sarebbe completamente differente che quello per un gioco di calcolatore a basso costo.
* Prova di accettabilit� da parte dell'utente - determinando se il software � soddisfacente ad un utilizzatore finale o ad un cliente.
* Prova di confronto - confrontare le debolezze e le resistenze del software ai prodotti competenti.
* Prova dell'alfa - prova di un'applicazione quando lo sviluppo sta essendo in via di realizzazione; i cambiamenti secondari di disegno possono ancora essere fatti come conseguenza di tale prova. Fatto tipicamente dagli utilizzatori finali o da altri, non dai programmatori o dai tester.
* La beta prova - esaminando quando lo sviluppo ed esaminare essenzialmente sono completati ed insetti e problemi finali deve essere trovata prima del rilascio finale. Fatto tipicamente dagli utilizzatori finali o da altri, non dai programmatori o dai tester.
* Prova di mutazione - un metodo per la determinazione se un insieme dei casi di dati di prova o della prova � utile, deliberatamente introducendo i vari cambiamenti di codice (�insetti�) e riprovando con i dati di prova/casi originali per determinare se �gli insetti� sono rilevati. L'esecuzione adeguata richiede le grandi risorse di calcolo.
11.What sono 5 problemi comuni nel processo di sviluppo del software?
* Requisiti solidi - liberi, requisiti completi, dettagliati, coesivi, raggiungibili, saggiabili che sono accosentiti tramite tutti i giocatori. Usare i prototipi per contribuire ad inchiodare gi� i requisiti. �In agile� - scrivere gli ambienti a macchina, coordinazione continua con i clienti/utilizzatori finali � necessario.
* Programmi realistichi - concedere il tempo sufficiente per la progettazione, il disegno, la prova, l'insetto che riparano, riprovare, cambiamenti e documentazione; i personali dovrebbero potere completare il progetto senza bruciare.
* Prova sufficiente - iniziare ad esaminare nella fase iniziale, riprovare dopo che difficolt� o cambiamenti, programma per tempo sufficiente per la prova e insetto-riparare. �Presto� esaminare idealmente include l'unit� che esamina dagli sviluppatori e prova di built-in e possibilit� diagnostiche.
* Attaccare ai requisiti iniziali il pi� possibile - essere preparato per difendere contro i cambiamenti e le aggiunte eccessivi una volta che lo sviluppo ha cominciato e per essere preparato per spiegare le conseguenze. Se i cambiamenti sono necessari, dovrebbero essere riflessi adeguatamente nei cambiamenti relativi di programma. Se possibile, lavorare molto attentamente con i clienti/utilizzatori finali per controllare le aspettative. Ci� fornir� loro un livello elevato di comodit� le loro decisioni di requisiti e minimizzer� i cambiamenti eccessivi pi� tardi.
* comunicazione - richiedere i walkthroughs ed i controlli una volta adatto; fare il vasto uso degli attrezzi di comunicazione del gruppo - E-mail, groupware, attrezzi d'inseguimento networked ed attrezzi di amministrazione del cambiamento, possibilit� del Intranet, ecc.; assicurare che l'informazione/documentazione � disponibili ed aggiornate - preferibilmente elettronico, non carta; promuovere il lavoro di squadra e la cooperazione; usare i protoypes se possibile chiarire le aspettative dei clienti.
12.What � software �qualit��?
* Il software di qualit� � ragionevolmente esente da errore, trasportato in tempo ed all'interno del preventivo, dei requisiti di raduni e/o delle aspettative ed � mantenibile. Tuttavia, la qualit� � ovviamente un termine soggettivo. Dipender� da chi �il cliente� � e la loro influenza generale nello schema delle cose. Un punto di vista grandangolare �dei clienti� di un progetto di sviluppo del software ha potuto includere gli utilizzatori finali, i tester di accettazione di cliente, gli ufficiali del contratto del cliente, l'amministrazione del cliente, l'organizzazione di sviluppo.
* Amministrazione/ragionieri/tester/commessi, assistenti tecnici futuri di manutenzione del software, azionisti, columnists dello scomparto, ecc. Ogni tipo �di cliente� avr� loro propria inclinazione �su qualit�� - l'ufficio contabilit� potrebbe definire la qualit� in termini di profitti mentre un utilizzatore finale potrebbe definire la qualit� come facile da usare ed esente da errore.
13.What � �buon codice�?
* * �il buon codice� � codice che funziona, � esente da errore ed � leggibile e mantenibile. Alcune organizzazioni hanno codificazione �campioni� a che tutti gli sviluppatori sono supposti di aderirsi, ma tutto ha idee differenti circa che cosa � il la cosa migliore, o che cosa � troppo o troppo poche regole. Ci � inoltre varie teorie e metrica, quale la metrica di complessit� di McCabe. Dovrebbe essere tenuta presente che l'uso eccessivo degli standard e delle norme pu� soffocare il rendimento e la creativit�. �Le revisioni di pari�, �compagno controlla� gli attrezzi di analisi di codice, ecc. pu� essere usato per controllare per vedere se ci sono problemi e per fare rispettare i campioni. Per codificazione di C++ e di C, qui sono alcune idee tipiche considerare nella regolazione le norme/standard; questi possono o meno applicarsi ad una situazione particolare:
* Minimizzare o eliminare l'uso delle variabili globali.
* Usare i nomi descrittivi di metodo e di funzione - usare entrambe la maiuscola e minusciola, evitare le abbreviazioni, usare altretanti caratteri secondo i bisogni per essere adeguatamente descrittivo (uso di pi� di 20 caratteri non � dalla linea); essere costante nel chiamare le convenzioni.
* Usare i nomi variabili descrittivi - usare entrambe la maiuscola e minusciola, evitare le abbreviazioni, usare altretanti caratteri secondo i bisogni per essere adeguatamente descrittivo (uso di pi� di 20 caratteri non � dalla linea); essere costante nel chiamare le convenzioni.
* I formati di metodo e di funzione dovrebbero essere minimizzati; pi� meno di 100 linee del codice � buone, pi� meno di 50 linee � preferibili.
* Le descrizioni di funzione dovrebbero essere spiegate chiaramente nelle osservazioni che precedono il codice della funzione.
* Organizzare il codice per la leggibilit�.
* Usare generoso il whitespace - verticalmente ed orizzontalmente.
* Ogni linea del codice dovrebbe contenere 70 caratteri massimi.
* Una dichiarazione di codice per la linea.
* Lo stile di codificazione dovrebbe essere throught costante un il programma (per esempio, uso delle staffe, delle rientranze, chiamanti le convenzioni, ecc.)
* Nella aggiunta delle osservazioni, errare sul lato di troppi piuttosto che su troppo poche osservazioni; una regola pratica comune � che ci dovrebbero essere almeno altretante linee delle osservazioni (blocchetti compresi dell'intestazione) come linee del codice.
* Non importa come piccola, un'applicazione dovrebbe includere documentaion della funzione generale di programma e fluire (persino alcuni paragrafi � migliori di niente); o se possibile un diagramma di flusso separato e una documentazione dettagliata di programma.
* Fare il vasto uso delle procedure di trattamento degli errori e di annotare di errore e di condizione.
* Per C++, minimizzare la complessit� ed aumentare la manutenzione, evitare troppi livelli dell'eredit� nei heirarchies del codice categoria (riguardante il formato e la complessit� dell'applicazione). Minimizzare l'uso dell'eredit� multipla e minimizzare l'uso di sovraccarico dell'operatore (nota che il linguaggio di programmazione del Java elimina l'eredit� multipla ed il sovraccarico dell'operatore.)
* Per C++, i metodi del codice categoria di conservazione piccoli, pi� meno di 50 linee del codice per il metodo � preferibili.
* Per C++, fare l'uso liberale degli alimentatori di eccezione.
14.What � �buon disegno�?
* * �il disegno� potrebbe riferirsi a molte cose, ma spesso si riferisce �al disegno funzionale� o �al disegno interno�. Il buon disegno interno � indicato vicino programma di cui la struttura generale � chiara, comprensibile, facilmente modifiable e mantenibile; � robusto con possibilit� annotare sufficiente di condizione e di errore-maneggiamento; ed impianti correttamente una volta effettuato. Il buon disegno funzionale � indicato da un'applicazione di cui la funzionalit� pu� essere seguita di nuovo ai requisiti dell'utilizzatore finale e del cliente. Per i programmi che hanno un'interfaccia di utente, � spesso una buona idea supporre che l'utilizzatore finale avr� poca conoscenza del calcolatore e non pu� leggere un manuale di utente o persino l'aiuto in linea; un certo regola-de-pollice comune include:
* Il programma dovrebbe comportarsi in un senso quel meno sorprese l'utente
* Dovrebbe sempre essere evidente all'utente che cosa pu� essere fatto dopo e come rimuovere
* Il programma non dovrebbe lasciare gli utenti fa qualche cosa di stupido senza avvertimento loro.
* SEI = �istituto di tecnologia della programmazione� all'universit� del Carnegie-Mellon; iniziato dal reparto della difesa degli Stati Uniti per contribuire a migliorare i processi di sviluppo del software.
* CMM = �modello di maturit� di possibilit��, ora denominato il CMMI (�integrazione del modello di maturit� di possibilit��), sviluppato dal SEI. � un modello di 5 livelli �della maturit�� trattata che determinano l'efficacia nel trasporto del software di qualit�. � adattato alle grandi organizzazioni quali i grandi appaltatori di reparto della difesa degli Stati Uniti. Tuttavia, molti dei processi di QA in questione sono adatti a tutta l'organizzazione e se ragionevolmente applicato possono essere utili. Le organizzazioni possono ricevere le valutazioni CMMI subendo le valutazioni dai revisori dei conti qualificati.
* Livello 1 - caratterizzato da caos, periodico si lascia prendere dal panico e gli sforzi eroici richiesti dagli individui per completare con successo i progetti. Pochi se qualsiasi processi sul posto; i successi non possono essere ripetibili.
* Livello 2 - l'inseguimento di progetto del software, l'amministrazione di requisiti, la progettazione realistica ed i processi dell'amministrazione di configurazione sono sul posto; le pratiche riuscite possono essere ripetute.
* Livello 3 - i processi di sviluppo e di manutenzione del software standard sono integrati durante un'organizzazione; un IS-IS del gruppo di processo di tecnologia della programmazione sul posto per sorvegliare i processi del software ed i programmi di formazione sono usati per accertare capire e la conformit�.
* Livello 4 - la metrica � usata per rintracciare il rendimento, i processi ed i prodotti. Le prestazioni di progetto sono prevedibili e la qualit� � costantemente alta.
* Livello 5 - il fuoco � su miglioramento trattato continouous. L'effetto di nuovi processi e tecnologie pu� essere previsto ed essere effettuato efficacemente una volta richiesto.
* Prospettiva CMM sulle valutazioni: Durante il 1997-2001, 1018 organizzazioni sono state valutate. Di quelli, 27% erano rated al Livello 1, 39% a 2, a 23% a 3, a 6% a 4 e a 5% a 5. (Per le valutazioni durante il periodo 1992-96, 62% era al Livello 1, 23% a 2, a 13% a 3, a 2% a 4 e a 0.4% a 5.) Il formato mediano delle organizzazioni era 100 personali di tecnologia/manutenzione della programmazione; 32% delle organizzazioni erano appaltatori federali o agenzie degli Stati Uniti. Per quelle valutate al Livello 1, la zona trattata chiave pi� problematica era nella garanzia della qualit� del software.
* Iso = �organizzazione internazionale per normalizzazione� - il campione di iso 9001:2000 (che sostituisce il livello precedente di 1994) li interessa i sistemi di qualit� che sono valutati dai revisori dei conti esterni e si applica a molti generi di organizzazioni di manufacturing e di produzione, software non giusto. Riguarda i processi della documentazione, di disegno, di sviluppo, di produzione, di prova, dell'installazione, di assistenza ed altro. L'insieme completo dei campioni consiste di: (a) Q9001-2000 - Sistemi di amministrazione di qualit�: Requisiti; (b) Q9000-2000 - Sistemi di amministrazione di qualit�: Fondamenti e vocabolario; (c) Q9004-2000 - Sistemi di amministrazione di qualit�: Guida di riferimento per i miglioramenti di prestazioni. Per essere iso 9001 certificato, un revisore dei conti di terzi valuta un'organizzazione e la certificazione � in genere buona per circa 3 anni, dopo di che una rivalutazione completa � richiesta. Si noti che la certificazione di iso necessariamente non indica i prodotti di qualit� - indica soltanto che i processi documentati sono seguiti. Inoltre vedere http://www.iso.ch/ per le ultime informazioni. Negli Stati Uniti i campioni possono essere comprati via il Web site di ASQ a http://e-standards.asq.org/
* IEEE = �istituto degli ingegneri elettronici ed elettrotecnici� - tra l'altro, genera i campioni come �il campione dello IEEE per la documentazione di prova del software� (campione 829 di IEEE/ANSI), 'il livello dello IEEE di prova di unit� del software (campione 1008 di IEEE/ANSI), �il campione dello IEEE per i programmi di garanzia della qualit� del software� (campione 730 di IEEE/ANSI) ed altri.
* ANSI = �American National Standards Institute�, l'organismo di normalizzazione industriali primario negli Stati Uniti; pubblica alcuni campioni software-relativi insieme con lo IEEE e il ASQ (societ� americana per qualit�).
* Altri metodi di valutazione di processo dell'amministrazione del software development/IT oltre a CMMI ed all'iso 9000 includono la SPEZIA, Trillium, TickIT, la linguetta per calzare gli stivali, ITIL, MOF e CobiT.
16.What � �il software ciclo di vita�?
* Il ciclo di vita comincia quando un'applicazione in primo luogo � concepita e si conclude quando non � pi� in uso. Include le funzioni quale il concetto iniziale, analisi di requisiti, disegno funzionale, disegno interno, pianificazione della documentazione, pianificazione della prova, codificazione, preparazione di documenti, integrazione, difficile, manutenzione, aggiornamenti, riprovanti, elimina ed altre funzioni.
gli attrezzi difficili automatizzati 17.Will rendono la prova pi� facile?
* Possibilmente per i progetti piccoli, il tempo necessario impararli ed effettuare non pu� valerlo. Per i pi� grandi progetti, o i progetti di lunga durata on-going possono essere utili.
* Un tipo comune di attrezzo automatizzato � �il tipo playback/dell'annotazione�. Per esempio, un tester ha potuto scattarsi con tutte le combinazioni delle scelte del menu, delle scelte della finestra di dialogo, dei tasti, ecc. in un GUI di applicazione e fare �registrare� loro ed i risultati essere annotato da un attrezzo. �La registrazione� � tipicamente sotto forma di testo basato su una lingua scripting che � interpretabile dall'attrezzo difficile. Se i nuovi tasti sono aggiunti, o un certo codice di fondo nell'applicazione � cambiato, ecc. l'applicazione potrebbe allora essere riprovato appena �giocando indietro� le azioni �registrate� e confrontando i risultati annotanti agli effetti del controllo dei cambiamenti. Il problema con tali attrezzi � che se ci sono cambiamenti continui al sistema che � esaminato, �le registrazioni� possono dovere essere cambiato cos� tanto che diventa molto che richiede tempo per aggiornare continuamente gli scritti. Ulteriormente, l'interpretazione e l'analisi dei risultati (schermi, dati, ceppi, ecc.) possono essere un'operazione difficile. Si noti che ci sono attrezzi playback/record per le interfacce basate testo inoltre e per tutti i tipi di piattaforme.
* Un altro tipo comune di metodo per automazione di prova funzionale � �prova automatizzata data-driven� o �parola-guidata�, in cui i driver della prova sono separati dai dati e/o dalle azioni utilizzati nella prova (�un'azione� sarebbe qualcosa come �fornisce un valore in una casella di testo�). I driver della prova possono essere sotto forma di gli attrezzi automatizzati della prova o il software difficile custom-written. I dati e le azioni possono essere effettuati pi� facilmente - quale via un foglio elettronico - poich� sono a parte dai driver della prova. I driver della prova �hanno letto� i dati/informazioni di azione per effettuare le prove specificate. Questo metodo pu� permettere il controllo, lo sviluppo, la documentazione e la manutenzione pi� efficienti delle prove/casi automatizzati della prova.
* Altri attrezzi automatizzati possono includere:
* Analizzatori di codice - controllare la complessit� di codice, l'aderenza ai campioni, ecc.
* Analizzatori di riempimento - questi attrezzi controllano quali parti del codice sono state esercitate da una prova e possono essere orientati verso riempimento di dichiarazione di codice, riempimento di circostanza, riempimento del percorso, ecc.
* Analizzatori di memoria - quali gli limit-ispettori ed i rivelatori della perdita.
* Attrezzi della prova prestazioni/del carico - per le applicazioni difficili del cliente/assistente e di fotoricettore sotto i vari livelli del carico.
* Attrezzi della prova di fotoricettore - controllare che i collegamenti siano validi, l'uso di codice del HTML � corretto, cliente-lato ed i programmi del assistente-lato funzionano, interazioni del Web site sono sicuri.
* Altri attrezzi - per l'amministrazione di caso della prova, l'amministrazione della documentazione, la segnalazione dell'insetto e l'amministrazione di configurazione.
