I trabocchetti dei progetti client/Server di sviluppo

Share

|

L'amministrazione dei progetti client/server comporta i trabocchetti unici all'interno delle categorie tradizionali di sviluppo dei sistemi. Questo articl richiama le caratteristiche uniche dei progetti client/server di sviluppo all'interno di seguenti categorie:

- requisiti di affari di Defining/documenting

- determinare i requisiti di hardware/software/network

- valutando

- inseguimento di progetto

- definire le mansioni

- valutare le ore ha richiesto

- valutare percentuale di completamento

- Timekeeping

- inseguimento dell'edizione

- abilità di sviluppo con tecnologia e gli attrezzi

- sicurezza

- processo di Testing/QA

- documentazione di sviluppo

- stabilità organizzativa

- Prototyping/usability

- chiusure del colloquio con il calcolatore ed approvazione

DEFINENDO E DOCUMENTANDO I REQUISITI DI AFFARI

Come con un progetto tradizionale di sviluppo, documentare i requisiti dovrebbe essere l'inizio di un progetto client/server di sviluppo. È qui che le esigenze degli utenti sono definite poichè una base dell'analisi di beneficio di valutazione e di costo di progetto. Il documento di requisiti dovrebbe essere dettagliato ed includere gli schermi dell'input, i cicli di elaborazione ed i rapporti di uscita. Il disegno di base di dati dovrebbe anche essere incluso, definendo i rapporti di dati. È non soltanto i requisiti di affari di defining/documenting importanti della valutazione dello sforzo iniziale del progetto, è inoltre critico per la determinazione dei cambiamenti nella portata e la determinazione del che cosa “fatto” è. Molte volte che cosa è rivisto con indifferenza all'inizio di un progetto diventa criticamente importanti nella determinazione del completamento’di progetto s. Gli elementi tipici di un documento di requisiti includono:

- obiettivo del project/system

- requisiti di affari

- requisiti dell'ingreso/uscita

- settore commerciale affected

- procedere i requisiti

- requisiti di sicurezza

- dati o lima che maneggiano i requisiti

- effetti organizzativi

- requisiti della documentazione

È difficile affinchè un revisore dei conti determini se tutti i requisiti sono completi e definiti adeguatamente. Tuttavia, ad un minimo, il revisore dei conti dovrebbe verificare che i requisiti sono definiti ad un livello sufficiente del particolare e che ci è autorizzazione adatta dell'amministrazione dell'utente.

DETERMINAZIONE FISSAGGI, SOFTWARE E DEI REQUISITI DELLA RETE

Una volta che le esigenze degli utenti sono definite, i requisiti di hardware/software/network possono essere stabiliti. Questi requisiti sono usati determinare la piattaforma e la rete d'elaborazione per il sistema. I fattori che determinano il platform(s) adatto sono l'infrastruttura della rete di existing/strategic, numero di utenti simultanei, formato della base di dati e volume delle transazioni. Non ci è tipicamente “giusta” piattaforma da usare e molti SONO personali hanno opinioni differenti. In più, i fornitori stanno annunciando sempre i nuovi rilasci con le nuove caratteristiche, rendente la difficile distinguere le caratteristiche di prodotto attuali contro vaporware. Guardisi da delle tecnologie e delle metodologie che introducono i nuovi termini e vernaculars che forniscono uno schermo di fumo per la povera gestione di progetti e la mancanza di perizia. Eventualmente, un metodo il migliore è scelto che considera il costo, le prestazioni dei sistemi e la facilità di sviluppo. Tipicamente, i requisiti sono documentati in un documento di architettura che includono:

- requisiti di affari

- considerazioni tattiche

- considerazioni strategiche

- interfacce con altri sistemi

Nessuna piattaforma dei hardware/software “misura” tutte le applicazioni, appena come martello da solo non costruirà una casa. Tuttavia, nessuna piccola parte della scelta della piattaforma dovrebbe essere che cosa le piattaforme gli sviluppatori hanno una conoscenza di con. La familiarità con le piattaforme scelte migliorerà l'esattezza delle valutazioni e contribuirà a accertarsi che “i problemi dell'assassino” del sistema non siano incontrati più successivamente. È troppo rischioso usare le tecnologie indimostrate come piattaforma per i grandi progetti di sviluppo.

Un ingorgo potenziale con i sistemi client/server è la capienza ed il traffico della rete fra la stazione di lavoro dell'utente e l'assistente. Molte volte, questi sistemi si pensano che effettuino le reti di zona larga eccessive (WAN) che non possono fornire i tempi di reazione costanti della rete.

VALUTAZIONE

Un uso della valutazione di progetto deve determinare se l'amministrazione desideri costituire un fondo per il progetto basato su un'analisi di cost/benefit. Ovviamente, se le valutazioni non sono esatte, l'amministrazione non può prendere le buone decisioni sopra se desiderano fare il progetto, assegna la gente alle mansioni, o al programma sopra quando i deliverables saranno disponibili. Essenzialmente, senza valutazioni delle merci, i responsabili di progetto non possono controllare. I fattori che entrano nelle valutazioni di merce sono:

- esperienza con gli attrezzi di hardware/software/network/development: Se gli sviluppatori non sono sperimentati con il platforms/tools, l'amministrazione dovrebbe rendersi conto che la valutazione non è probabilmente molto buona ed essere aspetta per spendere molto più sul progetto e prevedere fa ritardare.

- familiarità con i requisiti: Gli sviluppatori sono stati coinvolti nella definizione di requisiti? Se non, la valutazione non è ancora probabilmente molto buona; e sia aspettano per spendere molto più sul progetto e prevedere fa ritardare.

- sistemi attuali: È la nuova applicazione una riscrittura dei sistemi attuali in cui i requisiti di dati e di rapporti sono definiti? In caso affermativo, la valutazione può essere abbastanza esatta. Altrimenti, lo sforzo supplementare può essere richiesto ai Re - faccia il sistema per venire a contatto delle esigenze degli utenti.

Eventualmente, un'annotazione di pista degli sforzi simili di sviluppo può essere usata per fornire un controllo di realtà per le valutazioni. Ciò può anche essere usata mentre un controllo per gli sviluppatori in carico che possono riempire le loro valutazioni. Un fattore o una gamma di riservatezza dovrebbe essere una parte di questa valutazione. Ciò dare ad amministrazione un migliore-contenitore e un piano d'azione nel peggiore dei casi. Ciò concederebbe ad amministrazione la capacità di decidere non fare il progetto se potesse essere non scadenze troppo costose o probabili di raduno. Un trabocchetto finale da guardare fuori per è un insieme della data dell'obiettivo dall'amministrazione maggiore da impegnare dal personale addetto al programma. Se una data dall'alto in basso dell'obiettivo è fissata, ci è pressione sul personale di sviluppo “nuovamente dentro” alle valutazioni che non sono basate su che cosa è richiesto o pressione non avere valutazioni affatto.

INSEGUIMENTO DI PROGETTO

Come con tutti i progetti di sviluppo, essenziali al evitare o a controllare i trabocchetti client/server di sviluppo è la gestione di progetti efficace. Gli elementi hanno elencato sotto sono usati identificare dove il progetto è, ciò che resta e la quantità di sforzo restante.

- definire le mansioni: Le mansioni di sviluppo dovrebbero essere definite ad un formato che è abbastanza piccolo essere rintracciato facilmente ed espressivo. Il responsabile di progetto può controllare efficacemente un progetto se ci sono deliverables specifici con le ore chiaramente definite e frequentano le date dovute. Le grandi mansioni con i deliverables ambigui lo rendono difficile sapere se il progetto è nella difficoltà a tempo controllare efficacemente i trabocchetti. Le interdipendenze di operazione e l'assegnazione delle responsabilità sono particolarmente importanti per i progetti con le squadre relative multiple in cui può essere difficile da determinare chi è responsabile di che cosa.

- valutando ore richieste: Ciò dovrebbe essere fatta da qualcuno che sia sperimentato con che cosa è richiesto — eventualmente lo sviluppatore che effettuerà l'operazione. Ciò fornirebbe una certa proprietà o impegno a completamento di operazione.

- valutare percentuale di completamento: Ciò può essere una congettura inesatta se basato sulla quantità di lavoro che già è stato consumato per completare un'operazione. Dovrebbe essere basata sui deliverables definiti quale il numero di mansioni, di schermi, o di rapporti completati.

- Timekeeping: Timekeeping non è usato frequentemente efficacemente. Molti sviluppatori non registrano regolarmente il loro tempo o non mantengono una valutazione esatta delle ore spesa. Ciò lo rende difficile determinare la condizione di progetto. In più, l'omissione di registrare tutte le ore per questo progetto può indurre altri progetti ad essere sottovalutato se le ore registrate sono usate per le valutazioni future.

INSEGUIMENTO DELL'EDIZIONE

L'inseguimento dell'edizione può essere usato per raffinare i requisiti di progetto documentando e risolvendo le decisioni che non sono state contemplate durante la definizione originale di requisiti. Il ceppo delle edizioni è inoltre un buon veicolo per i problemi in sospeso d'inseguimento ed accertarsi che siano risolti prima che il sistema sia effettuato in produzione. Un trabocchetto comune con i sistemi client/server è la mancanza di stabilità dovuto le incompatibilità del software, gli errori della rete e le debolezze con la base di dati che maneggia gli aggiornamenti simultanei. Le edizioni dovrebbero essere appesantite nella severità “dai tappi di esposizione” “agli aumenti piacevoli” per dare la priorità allo sforzo di sviluppo. L'utente possedente del sistema dovrebbe essere quello per determinare se un problema è stato risolto, là come tendenza affinchè gli sviluppatori esiga prematuramente la risoluzione. Come con tutto il ceppo di problema, il ceppo dell'edizione dovrebbe contenere chi ha identificato l'edizione, la data che l'edizione è stata identificata e che comunicato stata, la severità, una descrizione dell'edizione e se risolto, il testo di risoluzione. Ciò può anche servire mentre una traccia di verifica delle decisioni ha fatto.

Le edizioni dovrebbero essere mantenute dopo che siano risolte per essere usate per tendere futuro. L'analisi di tendenza dovrebbe essere effettuata per rintracciare le edizioni di addestramento, così come i problemi con fissaggi, il software di sistemi operativi e l'altro software di applicazione. Se ogni errore è annotato, il ceppo delle edizioni può anche essere usato per rintracciare la stabilità generale del sistema. Il ceppo delle edizioni può essere usato per diagnosticare i problemi segnando le situazioni con esattezza dove il problema ha accaduto. Le informazioni di problema possono anche essere utili nell'ottenere l'assistenza del fornitore nella risoluzione di problema fornendo la prova libera di correlazione fra i problemi ed i prodotti del fornitore.

ABILITÀ DI SVILUPPO CON TECNOLOGIA E GLI ATTREZZI

La formazione pratica non è il senso imparare i nuovi attrezzi e le tecniche di sviluppo client/server. Uno sviluppatore dovrebbe certamente prendere l'aula o l'addestramento computerizzato (CBT). Tuttavia, gli sviluppatori non dovrebbero intraprendere i progetti su grande scala senza in primo luogo con successo completare i piccoli progetti. Ciò ridurrebbe il rischio di progetto permettendo che gli sviluppatori si dimostrino su un a scala ridotta e diano loro l'abilità più esattamente alla valutazione lo sforzo in questione. I responsabili di progetto dovrebbero anche essere addestrati nel controllo dei progetti progressivamente più grandi che mettono a fuoco sulle squadre multiple, sulle interdipendenze di operazione e sugli utenti multipli.

Sui più grandi progetti con le nuove tecnologie, ci può essere molta gente con differenti livelli di perizia che tentano di prendere le decisioni. Ci sono molti livelli di conoscenza. Ciò può variare dal ché persona ha letto dentro uno scomparto, a che cosa si sono sentiti da qualcun'altro, a che cosa conoscono da addestramento, a che cosa sanno dal funzionamento con un sistema o oltre l'esperienza di sviluppo.

I primi tre livelli di conoscenza sono ragionevolmente deboli ma abbastanza comuni. La gente che’ruoli di s dovrebbe essere controllata, basato su un riconoscimento del loro livello di conoscenza per accertarsi che le mansioni siano assegnate giustamente, valutazioni sono certo, così come quello le decisioni prese ed i sensi presi sono suono. I controlli di riferimento dovrebbero essere fatti per i nuovi impiegati e consulenti in materia della parte esterna che sostengono essere “esperti” per verificare il loro livello di perizia.

SICUREZZA

Un'esecuzione riuscita di sicurezza può essere difficile in un ambiente client/server dovuto i molti strati d'elaborazione che devono essere assicurati:

- stazione di lavoro del cliente. Storicamente, questo è stato un personal computer che ha limitazione debole di comandi chi ha accesso ai programmi ed alle lime. Tuttavia, con l'introduzione dei sistemi operativi quale la stazione di lavoro’di Windows NT del Microsoft s, i comandi disponibili stanno rivaleggiando con il livello di sicurezza disponibile su un elaboratore centrale.

- applicazione. Questo livello di sicurezza controlla tipicamente i menu ed i campi che un utente può accedere a. I livelli di accesso tipicamente sono letti, aggiornano e cancellano.

- rete. Ciò si occupa dell'assicurazione dell'attività sulla rete. Gli attrezzi quali le ventose della rete sono a disposizione indicare ed alterare i dati che sono trasmessi sulla rete. Ci sono in genere due tipi di comandi della rete usati per impedire la rilevazione o l'alterazione inadeguata dei dati. Il primo sta limitando l'accesso ai segmenti o alle zone di una rete. Ciò è fatta solitamente con i sistemi della parete refrattaria o i routers della selezione che limitano il traffico basato sulla fonte e sugli indirizzi di destinazione. I collegamenti del Internet dovrebbero essere controllati dalle pareti refrattarie. L'altro metodo per l'assicurazione del traffico della rete è la crittografia. Ciò impedisce la capacità di leggere o alterare i dati che vanno attraverso la rete. Ad un minimo, le parole d'accesso dovrebbero essere cifrate.

- assistente. Degli assistenti controllo tipicamente che può entrare alla rete e che può accedere alle basi di dati ed alle lime sulla rete. La sicurezza dell'assistente è la la maggior parte

tipo comune di sicurezza usato in una rete locale. L'accesso alla rete è in genere controllato con un userid e una parola d'accesso corrispondente. L'accesso alle lime allora è assegnato basato sull'identificazione assegnata di gruppo o dell'utente. La maggior parte dei assistenti provvedono ad attività annotante della gestione e di violazione di sicurezza. Nei grandi sistemi del cliente /server, un elaboratore centrale sta effettuando la funzione dell'assistente.

- base di dati. Il sistema della base di dati può anche effettuare le funzioni di sicurezza, richiedenti un userid e una parola d'accesso ed allora assegnanti l'accesso ai dati basati sull'identificazione di gruppo o dell'utente. In più, le basi di dati possono annotare l'attività della gestione e di violazione di sicurezza.

La coordinazione dei livelli multipli di sicurezza è difficile e molti sistemi introducono le debolezze di sicurezza ignorando i comandi di accesso su determinate piattaforme o scripting gli inizio attività sulle piattaforme che possono essere aggirate facilmente. Un altro problema tipico con i sistemi client/server è che sono ingombranti, richiedendo gli inizio attività multipli con i userids multipli e le parole d'accesso.

Nel migliore dei casi, l'applicazione dovrebbe essere progettata con un singolo sign-on a che i comandi accedono sul ation, sulla stazione di lavoro, sull'assistente e sui sistemi applic della base di dati, con i comandi della rete che limitano l'accesso ai segmenti adatti della rete e cifrano il traffico sensibile.

PROVA

Mentre gli elementi del processo tradizionale di qualità assurance/testing si applicano all'ambiente client/server, questo ambiente contiene le sfide uniche che richiedono la prova più rigorosa anche se gli sviluppatori non possono prendere la prova come seriamente perché è “soltanto un sistema del pc.” Il processo client/server di sviluppo dei sistemi dovrebbe includere i programmi di prova con il risultato previsto, il risultato reale e la disposizione delle differenze. Se i requisiti del sistema sono stati definiti bene, possono essere usati per sviluppare i programmi di prova. La prova dovrebbe includere tutte le piattaforme, così come le interfacce fra loro e la capacità maneggiare gli utenti simultanei. Oltre che il maneggiamento degli aggiornamenti multipli attraverso i collegamenti simultanei, molti sistemi client/server includono la capacità di funzionare senza un collegamento di rete diretto con sincronizzazione della base di dati usando una replica denominata trattata. Ciò richiede i punti difficili unici verificare che le aggiunte, gli aggiornamenti, o le omissioni ripiegati sono maneggiati correttamente con il processo della replica così come il funzionamento con il sistema che funziona in un multiplo - modo dell'utente. Gli aggiornamenti simultanei alle basi di dati (due genti che tentano di aggiornare la stessa annotazione allo stesso tempo) possono generare i conflitti della base di dati. Come il sistema maneggia i conflitti dovrebbero essere documentati e controllati dal software di applicazione o dalle procedure manuali.

Il povero tempo di reazione è spesso un'edizione con i sistemi client/server. Gli ingorghi possono essere corretti aumentando la capienza della rete, le domande di sintonia della base di dati, o l'ottimizzazione del disegno di base di dati.

L'amministrazione client/server del cambiamento inoltre genera le sfide uniche con controllo di versione. Il codice mming di Progra è distribuito tipicamente attraverso le piattaforme multiple così come incastonato all'interno delle basi di dati. Mentre i pacchetti di controllo di versione del pc sono usati frequentemente, cambi i sistemi di amministrazione che includono la sincronizzazione di source/object non sono specializzati quanto i sistemi usati nell'ambiente di elaboratore centrale.

DOCUMENTAZIONE DI SVILUPPO

Mentre l'obiettivo di un sistema client/server è di essere facile da usare e fornire le funzioni in linea di aiuto, questi sistemi dovrebbero ulteriormente avere i tipi tradizionali di documentazioni disponibili da funzionare, effettuano ed usano il sistema. I requisiti della documentazione dovrebbero includere quanto segue:

- descrizione del sistema

- codici dell'utente instructions/transaction

- diagrammi di flusso del sistema

- interfacce del sistema

- funzione di elaborazione, organizzazione e descrizione sommaria della spettrografia di massa di progra.

- caratteristiche della lima descriptions/dataset (disegno di base di dati se applicabile)

- requisiti di controllo e di sicurezza del sistema ed esecuzione di quei requisiti nel sistema

- requisiti del sostegno e di ritegno della lima - errori e messaggi dell'utente

I requisiti della documentazione dovrebbero essere inclusi nel programma di progetto, così come i contratti se funzionando con un fornitore esterno.

STABILITÀ ORGANIZZATIVA

Le riorganizzazioni ed il ricambio del personale sono difficili da controllare, specialmente nelle grandi organizzazioni. Questi effetti possono uccidere facilmente un progetto. Un buon responsabile di progetto prevedrà la possibilità di perdere i membri della squadra prima “delle due settimane che l'avviso” è dato. Ovviamente, l'amministrazione dovrebbe fare che cosa latta per mantenere la gente chiave. Tuttavia, il personale perdente è inevitabile — particolarmente se il personale è addestrato “sulle tecnologie calde” che sono molto commerciabili. Le cose che possono essere fatte per ridurre l'effetto dei cambiamenti del personale sono:

- addestramento: accertandosi che abbastanza gente sul personale sia informata con le tecnologie assicurare che la squadra non è eccessivamente fiduciosa in alcuna una persona. Ciò potrebbe anche essere usata per contribuire a controllare i personali che sono resistenti a cambiamento e non desidera occuparsi di esso.

- stabilire i sostegni: identificare chi potrebbero riempire una posizione’della persona s, che cosa prenderebbero per ottenere all'individuo fino a velocità ed effettuargli un programma prima sono richiesti. Può avere il significato per indicare gli individui di riserva scrive le parti del sistema per accertarsi che abbiano le abilità necessarie per sostenerlo.

- Mentoring: identificando le occasioni affinchè individui maggiori aiutino altri rispondendo alle domande, aiutando al ragionamento e funzionamento con i problemi.

- campioni di programmazione: coperture come il codice deve essere scritto e documentato per accertarsi che possa essere sostenuto da altri.

- rassegne di codice: coinvolge rivedere i sistemi mentre sono sviluppati per accertarsi che siano scritti logicamente, comprensibile da altri e per aderirsi ai campioni della documentazione.

- schermi di manutenzione: se sia costruito per permettere la modifica del sistema chiave functions/parameters senza intervento del programmatore.

CONCLUSIONE

Non è facile da controllare i progetti che dipendono dai sistemi client/server complessi. I problemi tecnici possono accadere che “uccidono un sistema” che ha niente a che fare con la gestione di progetti. Tuttavia, i comandi della gestione di progetti possono essere introdotti che attenuano i rischi di questi problemi. Mentre verificare la gestione che di progetti i comandi divergono dal metodo tradizionale di verifica, risorse corporative può essere conservata intensificando le situazioni dell'amministrazione maggiore dove questi comandi non sono sul posto. Come precedentemente discusso, i comandi più importanti per guardare fuori per per includere:

- esperienza con la tecnologia ed i progetti simili - adeguatamente definendo e documentando le esigenze degli utenti - date realistiche di valutazione e di stabilizzazione esatte dell'obiettivo - rintracciare progresso e le edizioni

- effettuare sicurezza efficace

- efficacemente documentando e verificando il sistema - ottenere approvazione dell'utente

Se questi comandi sono sul posto, il responsabile ed i revisori dei conti di progetto hanno certa assicurazione che i rischi connessi con i trabocchetti client/server stanno controllandi efficacemente.