Analisi e progettazione del sistema - Guida rapida

Lo sviluppo dei sistemi è un processo sistematico che include fasi come pianificazione, analisi, progettazione, implementazione e manutenzione. Qui, in questo tutorial, ci concentreremo principalmente su:

• Analisi dei sistemi
• Progettazione di sistemi

Analisi dei sistemi

È un processo di raccolta e interpretazione dei fatti, identificazione dei problemi e scomposizione di un sistema nei suoi componenti.

L'analisi del sistema è condotta allo scopo di studiare un sistema o sue parti al fine di identificarne gli obiettivi. È una tecnica di risoluzione dei problemi che migliora il sistema e garantisce che tutti i componenti del sistema funzionino in modo efficiente per raggiungere il loro scopo.

L'analisi specifica what the system should do.

Progettazione di sistemi

È un processo di pianificazione di un nuovo sistema aziendale o di sostituzione di un sistema esistente definendone i componenti o i moduli per soddisfare i requisiti specifici. Prima di pianificare, è necessario comprendere a fondo il vecchio sistema e determinare come utilizzare al meglio i computer per operare in modo efficiente.

System Design si concentra su how to accomplish the objective of the system.

System Analysis and Design (SAD) si concentra principalmente su:

• Systems
• Processes
• Technology

Cos'è un sistema?

La parola Sistema deriva dalla parola greca Systema, che significa una relazione organizzata tra qualsiasi insieme di componenti per raggiungere una causa o un obiettivo comune.

Un sistema è "un raggruppamento ordinato di componenti interdipendenti collegati tra loro secondo un piano per raggiungere un obiettivo specifico".

Vincoli di un sistema

Un sistema deve avere tre vincoli di base:

• Un sistema deve averne alcuni structure and behavior progettato per raggiungere un obiettivo predefinito.

• Interconnectivity e interdependence deve esistere tra i componenti del sistema.

• Il objectives of the organization avere un higher priority rispetto agli obiettivi dei suoi sottosistemi.

Ad esempio, sistema di gestione del traffico, sistema del libro paga, sistema bibliotecario automatico, sistema informativo delle risorse umane.

Proprietà di un sistema

Un sistema ha le seguenti proprietà:

Organizzazione

L'organizzazione implica struttura e ordine. È la disposizione dei componenti che aiuta a raggiungere obiettivi predeterminati.

Interazione

È definito dal modo in cui i componenti operano tra loro.

Ad esempio, in un'organizzazione, il reparto acquisti deve interagire con il reparto produzione e il libro paga con il reparto personale.

Interdipendenza

Interdipendenza significa come i componenti di un sistema dipendono l'uno dall'altro. Per un corretto funzionamento, i componenti sono coordinati e collegati tra loro secondo un piano specifico. L'output di un sottosistema è quello richiesto da un altro sottosistema come input.

Integrazione

L'integrazione riguarda il modo in cui i componenti di un sistema sono collegati insieme. Significa che le parti del sistema lavorano insieme all'interno del sistema anche se ciascuna parte svolge una funzione unica.

Obiettivo centrale

L'obiettivo del sistema deve essere centrale. Può essere reale o dichiarato. Non è raro che un'organizzazione stabilisca un obiettivo e operi per raggiungerne un altro.

Gli utenti devono conoscere l'obiettivo principale di un'applicazione per computer all'inizio dell'analisi per una progettazione e una conversione di successo.

Elementi di un sistema

Il diagramma seguente mostra gli elementi di un sistema:

Uscite e ingressi

• Lo scopo principale di un sistema è produrre un output utile per il suo utente.

• Gli input sono le informazioni che entrano nel sistema per l'elaborazione.

• L'output è il risultato dell'elaborazione.

Processore (i)

• Il processore è l'elemento di un sistema che prevede l'effettiva trasformazione dell'input in output.

• È la componente operativa di un sistema. I processori possono modificare l'input totalmente o parzialmente, a seconda delle specifiche dell'output.

• Man mano che le specifiche di output cambiano, cambia anche l'elaborazione. In alcuni casi, l'input viene modificato anche per consentire al processore di gestire la trasformazione.

Controllo

• L'elemento di controllo guida il sistema.

• È il sottosistema decisionale che controlla il modello di attività che governano input, elaborazione e output.

• Il comportamento di un sistema informatico è controllato dal sistema operativo e dal software. Per mantenere il sistema in equilibrio, cosa e quanto input è necessario è determinato dalle specifiche di output.

Risposta

• Il feedback fornisce il controllo in un sistema dinamico.

• Il feedback positivo è di routine in natura che incoraggia le prestazioni del sistema.

• Il feedback negativo è di natura informativa che fornisce al controller le informazioni per l'azione.

Ambiente

• L'ambiente è il “supersistema” all'interno del quale opera un'organizzazione.

• È la fonte di elementi esterni che colpiscono il sistema.

• Determina come deve funzionare un sistema. Ad esempio, fornitori e concorrenti dell'ambiente dell'organizzazione possono fornire vincoli che influiscono sulle prestazioni effettive dell'azienda.

Confini e interfaccia

• Un sistema dovrebbe essere definito dai suoi confini. I confini sono i limiti che identificano i suoi componenti, processi e interrelazioni quando si interfaccia con un altro sistema.

• Ogni sistema ha confini che determinano la sua sfera di influenza e controllo.

• La conoscenza dei confini di un dato sistema è cruciale per determinare la natura della sua interfaccia con altri sistemi per una progettazione di successo.

Tipi di sistemi

I sistemi possono essere suddivisi nelle seguenti tipologie:

Sistemi fisici o astratti

• I sistemi fisici sono entità tangibili. Possiamo toccarli e sentirli.

• Il sistema fisico può essere di natura statica o dinamica. Ad esempio, le scrivanie e le sedie sono le parti fisiche del centro informatico che sono statiche. Un computer programmato è un sistema dinamico in cui programmi, dati e applicazioni possono cambiare in base alle esigenze dell'utente.

• I sistemi astratti sono entità non fisiche o concettuali che possono essere formule, rappresentazione o modello di un sistema reale.

Sistemi aperti o chiusi

• Un sistema aperto deve interagire con il suo ambiente. Riceve input da e fornisce output all'esterno del sistema. Ad esempio, un sistema informativo che deve adattarsi alle mutevoli condizioni ambientali.

• Un sistema chiuso non interagisce con il suo ambiente. È isolato dalle influenze ambientali. Un sistema completamente chiuso è raro nella realtà.

Sistema adattivo e non adattivo

• Adaptive System risponde ai cambiamenti nell'ambiente in modo da migliorare le loro prestazioni e sopravvivere. Ad esempio, esseri umani, animali.

• Non Adaptive System è il sistema che non risponde all'ambiente. Ad esempio, le macchine.

Sistema permanente o temporaneo

• Il sistema permanente persiste a lungo. Ad esempio, le politiche aziendali.

• Il sistema temporaneo viene realizzato per un tempo specificato e successivamente vengono demoliti. Ad esempio, un sistema DJ è impostato per un programma e viene smontato dopo il programma.

Sistema naturale e prodotto

• I sistemi naturali sono creati dalla natura. Ad esempio, sistema solare, sistema stagionale.

• Manufactured System è il sistema artificiale. Ad esempio, razzi, dighe, treni.

Sistema deterministico o probabilistico

• Il sistema deterministico opera in modo prevedibile e l'interazione tra i componenti del sistema è nota con certezza. Ad esempio, due molecole di idrogeno e una molecola di ossigeno producono acqua.

• Il sistema probabilistico mostra un comportamento incerto. L'output esatto non è noto. Ad esempio, previsioni del tempo, consegna della posta.

Sociale, uomo-macchina, sistema macchina

• Il sistema sociale è fatto di persone. Ad esempio, club sociali, società.

• Nel sistema uomo-macchina, sia l'uomo che le macchine sono coinvolti per eseguire un compito particolare. Ad esempio, la programmazione del computer.

• Il sistema macchina è dove le interferenze umane vengono trascurate. Tutte le attività vengono eseguite dalla macchina. Ad esempio, un robot autonomo.

Sistemi informativi artificiali

• È un insieme interconnesso di risorse informative per gestire i dati per una particolare organizzazione, sotto il controllo di gestione diretto (DMC).

• Questo sistema include hardware, software, comunicazione, dati e applicazioni per produrre informazioni in base alle necessità di un'organizzazione.

  I sistemi di informazione creati dall'uomo sono suddivisi in tre tipi:

• Formal Information System - Si basa sul flusso di informazioni sotto forma di promemoria, istruzioni, ecc., Dal livello superiore a quello inferiore di gestione.

• Informal Information System - Questo è un sistema basato sui dipendenti che risolve i problemi legati al lavoro quotidiano.

• Computer Based System- Questo sistema dipende direttamente dal computer per la gestione delle applicazioni aziendali. Ad esempio, sistema bibliotecario automatico, sistema di prenotazione ferroviaria, sistema bancario, ecc.

Modelli di sistemi

Modelli schematici

• Un modello schematico è un grafico 2-D che mostra gli elementi del sistema e i loro collegamenti.

• Diverse frecce vengono utilizzate per mostrare il flusso di informazioni, il flusso di materiale e il feedback delle informazioni.

Modelli del sistema di flusso

• Un modello di sistema di flusso mostra il flusso ordinato di materiale, energia e informazioni che tengono insieme il sistema.

• La tecnica di valutazione e revisione del programma (PERT), ad esempio, viene utilizzata per astrarre un sistema del mondo reale sotto forma di modello.

Modelli statici di sistema

• Rappresentano una coppia di relazioni come attività-tempo o costo-quantità .

• Il diagramma di Gantt, ad esempio, fornisce un'immagine statica di una relazione attività-tempo.

Modelli di sistema dinamico

• Le organizzazioni imprenditoriali sono sistemi dinamici. Un modello dinamico approssima il tipo di organizzazione o applicazione con cui trattano gli analisti.

• Mostra uno stato del sistema in corso e in costante cambiamento. Si compone di:

  • Ingressi che entrano nel sistema

  • Il processore attraverso il quale avviene la trasformazione

  • I programmi richiesti per l'elaborazione

  • Gli output che risultano dall'elaborazione.

Categorie di informazioni

Esistono tre categorie di informazioni relative ai livelli manageriali e alle decisioni prese dai manager.

Informazioni strategiche

• Queste informazioni sono richieste dal top management per le politiche di pianificazione a lungo termine per i prossimi anni. Ad esempio, tendenze in termini di entrate, investimenti finanziari e risorse umane e crescita della popolazione.

• Questo tipo di informazioni si ottiene con l'ausilio del Decision Support System (DSS).

Informazioni manageriali

• Questo tipo di informazioni è richiesto dal middle management per la pianificazione a breve e intermedio raggio che è in termini di mesi. Ad esempio, analisi delle vendite, proiezione del flusso di cassa e rendiconti finanziari annuali.

• Si ottiene con l'ausilio di Management Information Systems (MIS).

Informazioni operative

• Questo tipo di informazioni è richiesto dalla bassa dirigenza per la pianificazione quotidiana ea breve termine per applicare le attività operative quotidiane. Ad esempio, mantenere i registri delle presenze dei dipendenti, gli ordini di acquisto scaduti e le scorte correnti disponibili.

• Si ottiene con l'ausilio di Data Processing Systems (DPS).

Un ciclo di vita dello sviluppo del sistema (SDLC) efficace dovrebbe tradursi in un sistema di alta qualità che soddisfi le aspettative dei clienti, raggiunga il completamento entro le valutazioni di tempi e costi e funzioni in modo efficace ed efficiente nell'infrastruttura informatica attuale e pianificata.

Il ciclo di vita dello sviluppo del sistema (SDLC) è un modello concettuale che include politiche e procedure per lo sviluppo o l'alterazione dei sistemi durante i loro cicli di vita.

SDLC viene utilizzato dagli analisti per sviluppare un sistema informativo. SDLC include le seguenti attività:

• requirements
• design
• implementation
• testing
• deployment
• operations
• maintenance

Fasi di SDLC

Il ciclo di vita dello sviluppo dei sistemi è un approccio sistematico che suddivide esplicitamente il lavoro in fasi necessarie per implementare il sistema informativo nuovo o modificato.

Studio di fattibilità o pianificazione

• Definire il problema e l'ambito del sistema esistente.

• Panoramica del nuovo sistema e determinazione dei suoi obiettivi.

• Confermare la fattibilità del progetto e produrre la pianificazione del progetto.

• Durante questa fase vengono considerati anche minacce, vincoli, integrazione e sicurezza del sistema.

• Al termine di questa fase viene creato un report di fattibilità per l'intero progetto.

Analisi e specifiche

• Raccogli, analizza e convalida le informazioni.

• Definire i requisiti e i prototipi per il nuovo sistema.

• Valuta le alternative e dai la priorità ai requisiti.

• Esamina le esigenze di informazione dell'utente finale e migliora l'obiettivo del sistema.

• Alla fine di questa fase viene preparato un documento SRS (Software Requirement Specification), che specifica i requisiti software, hardware, funzionali e di rete del sistema.

Sistema di design

• Include la progettazione di applicazioni, rete, database, interfacce utente e interfacce di sistema.

• Trasforma il documento SRS in una struttura logica, che contiene una serie completa e dettagliata di specifiche che possono essere implementate in un linguaggio di programmazione.

• Creare un piano di emergenza, formazione, manutenzione e funzionamento.

• Rivedi il progetto proposto. Assicurarsi che il progetto finale deve soddisfare i requisiti indicati nel documento SRS.

• Infine, prepara un documento di progettazione che verrà utilizzato nelle fasi successive.

Implementazione

• Implementa il progetto nel codice sorgente attraverso la codifica.

• Combina tutti i moduli insieme in un ambiente di formazione che rileva errori e difetti.

• Un report di test che contiene errori viene preparato tramite un piano di test che include attività correlate ai test come la generazione di casi di test, i criteri di test e l'allocazione di risorse per i test.

• Integrare il sistema informativo nel suo ambiente e installare il nuovo sistema.

Manutenzione / supporto

• Includere tutte le attività come il supporto telefonico o il supporto fisico in loco per gli utenti che è richiesto una volta che il sistema è stato installato.

• Implementare le modifiche che il software potrebbe subire per un periodo di tempo o implementare eventuali nuovi requisiti dopo che il software è stato distribuito presso la sede del cliente.

• Include anche la gestione degli errori residui e la risoluzione di eventuali problemi che possono esistere nel sistema anche dopo la fase di test.

• La manutenzione e il supporto possono essere necessari per un periodo più lungo per sistemi di grandi dimensioni e per un breve periodo per sistemi più piccoli.

Ciclo di vita dell'analisi e della progettazione del sistema

Il diagramma seguente mostra il ciclo di vita completo del sistema durante la fase di analisi e progettazione.

Ruolo dell'analista di sistema

L'analista di sistema è una persona che conosce a fondo il sistema e guida il progetto di sviluppo del sistema fornendo indicazioni adeguate. È un esperto con capacità tecniche e interpersonali per svolgere i compiti di sviluppo richiesti in ogni fase.

Si prefigge di far coincidere gli obiettivi del sistema informativo con l'obiettivo dell'organizzazione.

Ruoli principali

• Definizione e comprensione dei requisiti dell'utente attraverso varie tecniche di accertamento dei fatti.

• Dare priorità ai requisiti ottenendo il consenso degli utenti.

• Raccogliere fatti o informazioni e acquisire le opinioni degli utenti.

• Mantiene analisi e valutazione per arrivare a un sistema appropriato che sia più facile da usare.

• Suggerisce molte soluzioni alternative flessibili, scegli la soluzione migliore e quantifica costi e vantaggi.

• Disegna alcune specifiche che sono facilmente comprese dagli utenti e dal programmatore in forma precisa e dettagliata.

• Implementato il design logico del sistema che deve essere modulare.

• Pianificare la periodicità per la valutazione dopo che è stato utilizzato per un po 'di tempo e modificare il sistema secondo necessità.

Attributi di un analista di sistema

La figura seguente mostra gli attributi che un analista di sistema dovrebbe possedere:

Abilità interpersonali

• Interfaccia con utenti e programmatore.
• Facilita i gruppi e guida i team più piccoli.
• Gestire le aspettative.
• Buone capacità di comprensione, comunicazione, vendita e insegnamento.
• Motivatore che ha la fiducia necessaria per risolvere le domande.

Capacità analitiche

• Studio del sistema e conoscenza organizzativa
• Identificazione del problema, analisi del problema e risoluzione dei problemi
• Buon buon senso
• Possibilità di accedere al trade-off
• Curiosità per conoscere una nuova organizzazione

Abilità manageriali

• Comprendere il gergo e le pratiche degli utenti.
• Gestione delle risorse e dei progetti.
• Gestione del cambiamento e del rischio.
• Comprendere a fondo le funzioni di gestione.

Abilità tecniche

• Conoscenza di computer e software.
• Tenere il passo con lo sviluppo moderno.
• Conoscere gli strumenti di progettazione del sistema.
• Ampia conoscenza delle nuove tecnologie.

Che cos'è la determinazione dei requisiti?

Un requisito è una caratteristica vitale di un nuovo sistema che può includere l'elaborazione o l'acquisizione di dati, il controllo delle attività aziendali, la produzione di informazioni e il supporto alla gestione.

La determinazione dei requisiti implica lo studio del sistema esistente e la raccolta di dettagli per scoprire quali sono i requisiti, come funziona e dove è necessario apportare miglioramenti.

Attività principali nella determinazione dei requisiti

Requisiti Anticipazione

• Prevede le caratteristiche del sistema sulla base di precedenti esperienze che includono determinati problemi o caratteristiche e requisiti per un nuovo sistema.

• Può portare all'analisi di aree che altrimenti sarebbero passate inosservate da analisti inesperti. Ma se vengono prese scorciatoie e vengono introdotti pregiudizi nella conduzione dell'indagine, l'anticipazione dei requisiti può essere incompleta.

Indagine sui requisiti

• Sta studiando il sistema attuale e documentando le sue caratteristiche per ulteriori analisi.

• È al centro dell'analisi del sistema dove l'analista documenta e descrive le caratteristiche del sistema utilizzando tecniche di ricerca dei fatti, prototipazione e strumenti assistiti da computer.

Specifiche dei requisiti

• Comprende l'analisi dei dati che determinano la specifica dei requisiti, la descrizione delle caratteristiche del nuovo sistema e la specificazione dei requisiti di informazione che verranno forniti.

• Comprende l'analisi dei dati fattuali, l'identificazione dei requisiti essenziali e la selezione delle strategie di adempimento dei requisiti.

Tecniche di raccolta delle informazioni

Lo scopo principale delle tecniche di accertamento dei fatti è determinare i requisiti di informazione di un'organizzazione utilizzati dagli analisti per preparare un preciso SRS comprensibile dall'utente.

Il documento SRS ideale dovrebbe:

• essere completo, non ambiguo e privo di gergo.
• specificare i requisiti informativi operativi, tattici e strategici.
• risolvere eventuali controversie tra utenti e analista.
• utilizzare supporti grafici che semplificano la comprensione e la progettazione.

Esistono varie tecniche di raccolta delle informazioni:

Colloquio

L'analista di sistema raccoglie informazioni da individui o gruppi tramite interviste. L'analista può essere formale, legalista, fare politica o essere informale; poiché il successo di un colloquio dipende dall'abilità dell'analista come intervistatore.

Può essere fatto in due modi:

• Unstructured Interview - L'analista di sistema conduce una sessione di domande e risposte per acquisire le informazioni di base del sistema.

• Structured Interview - Ha domande standard a cui l'utente deve rispondere in formato chiuso (obiettivo) o aperto (descrittivo).

Advantages of Interviewing

• Questo metodo è spesso la migliore fonte per raccogliere informazioni qualitative.

• È utile per loro, che non comunicano efficacemente per iscritto o che potrebbero non avere il tempo di completare il questionario.

• Le informazioni possono essere facilmente convalidate e verificate immediatamente.

• Può trattare argomenti complessi.

• È facile scoprire il problema chiave cercando opinioni.

• Colma le lacune nelle aree di incomprensioni e riduce al minimo i problemi futuri.

Questionari

Questo metodo viene utilizzato dall'analista per raccogliere informazioni su vari problemi del sistema da un gran numero di persone.

Esistono due tipi di questionari:

• Open-ended Questionnaires- Consiste di domande che possono essere interpretate facilmente e correttamente. Possono esplorare un problema e portare a una specifica direzione di risposta.

• Closed-ended Questionnaires - Consiste in domande che vengono utilizzate quando l'analista di sistema elenca efficacemente tutte le possibili risposte, che si escludono a vicenda.

Advantages of questionnaires

• È molto efficace nel rilevare interessi, atteggiamenti, sentimenti e convinzioni degli utenti che non si trovano nella stessa posizione.

• È utile in una situazione sapere quale percentuale di un dato gruppo approva o disapprova una particolare caratteristica del sistema proposto.

• È utile determinare il giudizio complessivo prima di dare una direzione specifica al progetto del sistema.

• È più affidabile e fornisce un'elevata riservatezza delle risposte oneste.

• È appropriato per l'elezione di informazioni fattuali e per la raccolta di dati statistici che possono essere inviati per posta elettronica e inviati per posta.

Revisione di registrazioni, procedure e moduli

La revisione di record, procedure e moduli esistenti aiuta a cercare informazioni su un sistema che descrive le capacità del sistema corrente, le sue operazioni o attività.

Advantages

• Aiuta l'utente ad acquisire una certa conoscenza dell'organizzazione o delle operazioni da solo prima di imporsi ad altri.

• Aiuta a documentare le operazioni correnti in un breve lasso di tempo poiché i manuali e i moduli delle procedure descrivono il formato e le funzioni del sistema attuale.

• Può fornire una chiara comprensione delle transazioni gestite nell'organizzazione, identificando gli input per l'elaborazione e valutando le prestazioni.

• Può aiutare un analista a comprendere il sistema in termini di operazioni che devono essere supportate.

• Descrive il problema, le sue parti interessate e la soluzione proposta.

Osservazione

Questo è un metodo per raccogliere informazioni notando e osservando persone, eventi e oggetti. L'analista visita l'organizzazione per osservare il funzionamento del sistema corrente e comprende i requisiti del sistema.

Advantages

• È un metodo diretto per raccogliere informazioni.

• È utile in situazioni in cui è in questione l'autenticità dei dati raccolti o quando la complessità di alcuni aspetti del sistema impedisce una chiara spiegazione da parte degli utenti finali.

• Produce dati più accurati e affidabili.

• Produce tutti gli aspetti della documentazione che sono incompleti e obsoleti.

Sviluppo di applicazioni congiunte (JAD)

È una nuova tecnica sviluppata da IBM che porta proprietari, utenti, analisti, designer e costruttori a definire e progettare il sistema utilizzando workshop organizzati e intensivi. L'analista formato da JAD funge da facilitatore per il workshop che ha alcune abilità specialistiche.

Advantages of JAD

• Risparmia tempo e denaro sostituendo mesi di colloqui tradizionali e riunioni di follow-up.

• È utile nella cultura organizzativa che supporta la risoluzione congiunta dei problemi.

• Promuove relazioni formali tra più livelli di dipendenti.

• Può portare allo sviluppo del design in modo creativo.

• Consente un rapido sviluppo e migliora la proprietà del sistema informativo.

Ricerca secondaria o lettura di sfondo

Questo metodo è ampiamente utilizzato per la raccolta di informazioni accedendo alle informazioni raccolte. Include tutte le informazioni raccolte in precedenza utilizzate dall'operatore di marketing da qualsiasi fonte interna o esterna.

Advantages

• È accessibile in modo più aperto con la disponibilità di Internet.

• Fornisce informazioni preziose con costi e tempi ridotti.

• Agisce come precursore della ricerca primaria e allinea il focus della ricerca primaria.

• Viene utilizzato dal ricercatore per concludere se la ricerca vale la pena in quanto è disponibile con le procedure utilizzate e le problematiche nella loro raccolta.

Studio di fattibilità

Lo studio di fattibilità può essere considerato un'indagine preliminare che aiuta la direzione a prendere la decisione se lo studio del sistema dovrebbe essere fattibile per lo sviluppo o meno.

• Identifica la possibilità di migliorare un sistema esistente, sviluppare un nuovo sistema e produrre stime raffinate per un ulteriore sviluppo del sistema.

• Viene utilizzato per ottenere lo schema del problema e decidere se esiste o meno una soluzione fattibile o appropriata.

• L'obiettivo principale di uno studio di fattibilità è acquisire l'ambito del problema invece di risolverlo.

• L'output di uno studio di fattibilità è una proposta di sistema formale che funge da documento decisionale che include la natura completa e l'ambito del sistema proposto.

Fasi coinvolte nell'analisi di fattibilità

I seguenti passaggi devono essere seguiti durante l'esecuzione dell'analisi di fattibilità:

• Formare un team di progetto e nominare un capo progetto.

• Sviluppa diagrammi di flusso del sistema.

• Identificare le carenze del sistema attuale e fissare gli obiettivi.

• Enumerare la soluzione alternativa o il potenziale sistema candidato per raggiungere gli obiettivi.

• Determina la fattibilità di ciascuna alternativa come fattibilità tecnica, fattibilità operativa, ecc.

• Ponderare le prestazioni e l'economicità di ciascun sistema candidato.

• Classifica le altre alternative e seleziona il miglior sistema candidato.

• Preparare una proposta di sistema della direttiva di progetto finale alla direzione per l'approvazione.

Tipi di fattibilità

Fattibilità economica

• Sta valutando l'efficacia del sistema candidato utilizzando il metodo di analisi costi / benefici.

• Dimostra il vantaggio netto del sistema candidato in termini di costi e benefici per l'organizzazione.

• L'obiettivo principale dell'analisi di fattibilità economica (EFS) è stimare i requisiti economici del sistema candidato prima che i fondi di investimento siano impegnati nella proposta.

• Preferisce l'alternativa che massimizzerà il patrimonio netto dell'organizzazione con il più rapido e più alto rendimento dei fondi insieme al più basso livello di rischio coinvolto nello sviluppo del sistema candidato.

Fattibilità tecnica

• Indaga la fattibilità tecnica di ogni alternativa di implementazione.

• Analizza e determina se la soluzione può essere supportata dalla tecnologia esistente o meno.

• L'analista determina se le attuali risorse tecniche devono essere aggiornate o aggiunte che soddisfano i nuovi requisiti.

• Assicura che il sistema candidato fornisca risposte appropriate fino a che punto può supportare il miglioramento tecnico.

Fattibilità operativa

• Determina se il sistema funziona in modo efficace una volta sviluppato e implementato.

• Assicura che la direzione supporti il ​​sistema proposto e il suo funzionamento fattibile nell'attuale ambiente organizzativo.

• Analizza se gli utenti saranno interessati e accettano i metodi di business modificati o nuovi che influiscono sui possibili vantaggi del sistema.

• Assicura inoltre che le risorse del computer e l'architettura di rete del sistema candidato siano utilizzabili.

Fattibilità comportamentale

• Valuta e stima l'atteggiamento o il comportamento dell'utente nei confronti dello sviluppo di un nuovo sistema.

• Aiuta a determinare se il sistema richiede uno sforzo speciale per istruire, riqualificare, trasferire e modificare lo stato lavorativo dei dipendenti su nuovi modi di condurre gli affari.

Fattibilità del programma

• Assicura che il progetto debba essere completato entro un determinato limite di tempo o programma.

• Inoltre verifica e convalida se le scadenze del progetto sono ragionevoli o meno.

Gli analisti utilizzano vari strumenti per comprendere e descrivere il sistema informativo. Uno dei modi è utilizzare l'analisi strutturata.

Cos'è l'analisi strutturata?

L'analisi strutturata è un metodo di sviluppo che consente all'analista di comprendere il sistema e le sue attività in modo logico.

Si tratta di un approccio sistematico, che utilizza strumenti grafici che analizzano e perfezionano gli obiettivi di un sistema esistente e sviluppano una nuova specifica di sistema che può essere facilmente comprensibile dall'utente.

Ha i seguenti attributi:

• È un grafico che specifica la presentazione dell'applicazione.

• Divide i processi in modo da fornire un'immagine chiara del flusso del sistema.

• È logico piuttosto che fisico, ovvero gli elementi del sistema non dipendono dal fornitore o dall'hardware.

• È un approccio che funziona da panoramiche di alto livello a dettagli di livello inferiore.

Strumenti di analisi strutturata

Durante l'Analisi Strutturata, vengono utilizzati vari strumenti e tecniche per lo sviluppo del sistema. Sono -

• Diagrammi di flusso di dati
• Dizionario dei dati
• Alberi decisionali
• Tabelle delle decisioni
• Inglese strutturato
• Pseudocode

Diagrammi di flusso di dati (DFD) o grafico a bolle

È una tecnica sviluppata da Larry Constantine per esprimere i requisiti del sistema in una forma grafica.

• Mostra il flusso di dati tra le varie funzioni del sistema e specifica come viene implementato il sistema corrente.

• È una fase iniziale della fase di progettazione che suddivide funzionalmente le specifiche dei requisiti fino al livello di dettaglio più basso.

• La sua natura grafica lo rende un buon strumento di comunicazione tra utente e analista o analista e progettista di sistemi.

• Fornisce una panoramica di quali dati elabora un sistema, quali trasformazioni vengono eseguite, quali dati vengono archiviati, quali risultati vengono prodotti e dove fluiscono.

Elementi di base di DFD

DFD è facile da capire e abbastanza efficace quando il design richiesto non è chiaro e l'utente desidera un linguaggio notazionale per la comunicazione. Tuttavia, richiede un gran numero di iterazioni per ottenere la soluzione più accurata e completa.

La tabella seguente mostra i simboli utilizzati nella progettazione di un DFD e il loro significato:

Nome simbolo	Simbolo	Senso
Piazza		Origine o destinazione dei dati
Freccia		Flusso di dati
Cerchio		Processo di trasformazione del flusso di dati
Rettangolo aperto		Archivio dati

Tipi di DFD

I DFD sono di due tipi: DFD fisico e DFD logico. La tabella seguente elenca i punti che differenziano un DFD fisico da un DFD logico.

DFD fisico	DFD logico
Dipende dall'implementazione. Mostra quali funzioni vengono eseguite.	È indipendente dall'implementazione. Si concentra solo sul flusso di dati tra i processi.
Fornisce dettagli di basso livello su hardware, software, file e persone.	Spiega eventi di sistemi e dati richiesti da ciascun evento.
Descrive come funziona il sistema attuale e come verrà implementato un sistema.	Mostra come opera il business; non come il sistema può essere implementato.

Diagramma di contesto

Un diagramma di contesto aiuta a comprendere l'intero sistema da un DFD che fornisce la panoramica di un sistema. Inizia menzionando i processi principali con piccoli dettagli e poi passa a fornire maggiori dettagli dei processi con l'approccio top-down.

Di seguito è mostrato il diagramma di contesto della gestione della confusione.

Dizionario dei dati

Un dizionario dati è un archivio strutturato di elementi di dati nel sistema. Memorizza le descrizioni di tutti gli elementi di dati DFD, ovvero i dettagli e le definizioni dei flussi di dati, gli archivi dati, i dati archiviati negli archivi dati e i processi.

Un dizionario dati migliora la comunicazione tra l'analista e l'utente. Svolge un ruolo importante nella creazione di un database. La maggior parte dei DBMS dispone di un dizionario dati come funzionalità standard. Ad esempio, fare riferimento alla seguente tabella:

Sr.No.	Nome dati	Descrizione	No. di personaggi
1	ISBN	Numero ISBN	10
2	TITOLO	titolo	60
3	SUB	Soggetti del libro	80
4	UN NOME	Nome dell'autore	15

Alberi decisionali

Gli alberi decisionali sono un metodo per definire relazioni complesse descrivendo le decisioni ed evitando i problemi nella comunicazione. Un albero decisionale è un diagramma che mostra azioni e condizioni alternative all'interno della struttura ad albero orizzontale. Quindi, descrive quali condizioni considerare prima, seconda e così via.

Gli alberi decisionali rappresentano la relazione di ciascuna condizione e le loro azioni consentite. Un nodo quadrato indica un'azione e un cerchio indica una condizione. Costringe gli analisti a considerare la sequenza delle decisioni e identifica la decisione effettiva che deve essere presa.

Il limite principale di un albero decisionale è che manca di informazioni nel suo formato per descrivere quali altre combinazioni di condizioni è possibile adottare per il test. È un'unica rappresentazione delle relazioni tra condizioni e azioni.

Ad esempio, fare riferimento al seguente albero decisionale:

Tabelle delle decisioni

Le tabelle delle decisioni sono un metodo per descrivere la complessa relazione logica in un modo preciso e facilmente comprensibile.

• È utile in situazioni in cui le azioni risultanti dipendono dal verificarsi di una o più combinazioni di condizioni indipendenti.

• È una matrice contenente righe o colonne per definire un problema e le azioni.

Componenti di una tabella delle decisioni

• Condition Stub - È nel quadrante in alto a sinistra che elenca tutte le condizioni da controllare.

• Action Stub - È nel quadrante in basso a sinistra che delinea tutte le azioni da compiere per soddisfare tale condizione.

• Condition Entry - È nel quadrante in alto a destra che fornisce le risposte alle domande poste nel quadrante stub della condizione.

• Action Entry - È nel quadrante in basso a destra che indica l'azione appropriata risultante dalle risposte alle condizioni nel quadrante di ingresso della condizione.

Le voci nella tabella delle decisioni sono fornite dalle Regole di decisione che definiscono le relazioni tra combinazioni di condizioni e linee di condotta. Nella sezione regole,

• Y mostra l'esistenza di una condizione.
• N rappresenta la condizione, che non è soddisfatta.
• Uno spazio vuoto - contro l'azione afferma che deve essere ignorato.
• X (o un segno di spunta andrà bene) contro l'azione afferma che deve essere eseguita.

Ad esempio, fare riferimento alla seguente tabella:

CONDIZIONI	Regola 1	Regola 2	Regola 3	Regola 4
Pagamento anticipato effettuato	Y	N	N	N
Importo dell'acquisto = Rs 10.000 / -	-	Y	Y	N
Cliente abituale	-	Y	N	-
ACTIONS
Dare uno sconto del 5%	X	X	-	-
Non dare sconti	-	-	X	X

Inglese strutturato

L'inglese di struttura deriva dal linguaggio di programmazione strutturato che fornisce una descrizione più comprensibile e precisa del processo. Si basa sulla logica procedurale che utilizza frasi costruttive e imperative progettate per eseguire operazioni per l'azione.

• È utilizzato al meglio quando è necessario considerare sequenze e loop in un programma e il problema richiede sequenze di azioni con decisioni.

• Non ha una regola di sintassi rigida. Esprime tutta la logica in termini di strutture decisionali sequenziali e iterazioni.

Ad esempio, vedere la seguente sequenza di azioni:

if customer pays advance 
   then 
      Give 5% Discount 
   else 
      if purchase amount >=10,000 
         then 
            if  the customer is a regular customer 
               then Give 5% Discount 
            else  No Discount
         end if 
      else No Discount  
   end if 
end if

Pseudocodice

Uno pseudocodice non è conforme a nessun linguaggio di programmazione ed esprime la logica in un inglese semplice.

• Può specificare la logica di programmazione fisica senza la codifica effettiva durante e dopo la progettazione fisica.

• Viene utilizzato insieme alla programmazione strutturata.

• Sostituisce i diagrammi di flusso di un programma.

Linee guida per la selezione di strumenti appropriati

Utilizzare le seguenti linee guida per selezionare lo strumento più appropriato che soddisfi le proprie esigenze:

• Utilizzare DFD per analisi di alto o basso livello per fornire una buona documentazione di sistema.

• Utilizzare il dizionario dei dati per semplificare la struttura per soddisfare i requisiti di dati del sistema.

• Usa l'inglese strutturato se ci sono molti cicli e le azioni sono complesse.

• Utilizzare le tabelle delle decisioni quando è presente un numero elevato di condizioni da controllare e la logica è complessa.

• Utilizzare alberi decisionali quando la sequenza delle condizioni è importante e se ci sono poche condizioni da testare.

System designè la fase che colma in modo gestibile il divario tra dominio problematico e sistema esistente. Questa fase si concentra sul dominio della soluzione, ovvero "come implementare?"

È la fase in cui il documento SRS viene convertito in un formato che può essere implementato e decide come funzionerà il sistema.

In questa fase, la complessa attività di sviluppo del sistema è suddivisa in diverse sotto-attività minori, che si coordinano tra loro per raggiungere l'obiettivo principale dello sviluppo del sistema.

Input alla progettazione del sistema

La progettazione del sistema richiede i seguenti input:

• Dichiarazione di lavoro

• Piano di determinazione dei requisiti

• Analisi della situazione attuale

• Requisiti di sistema proposti tra cui un modello di dati concettuale, DFD modificati e metadati (dati sui dati).

Uscite per la progettazione del sistema

La progettazione del sistema fornisce i seguenti risultati:

• Cambiamenti infrastrutturali e organizzativi per il sistema proposto.

• Uno schema di dati, spesso uno schema relazionale.

• Metadati per definire tabelle / file e colonne / elementi di dati.

• Un diagramma della gerarchia delle funzioni o una mappa di una pagina Web che descrive graficamente la struttura del programma.

• Reale o pseudocodice per ogni modulo del programma.

• Un prototipo per il sistema proposto.

Tipi di progettazione del sistema

Progettazione logica

Il design logico riguarda una rappresentazione astratta del flusso di dati, input e output del sistema. Descrive gli input (sorgenti), output (destinazioni), database (archivi di dati), procedure (flussi di dati) il tutto in un formato che soddisfa i requisiti dell'utente.

Durante la preparazione della progettazione logica di un sistema, l'analista di sistema specifica le esigenze dell'utente a un livello di dettaglio che determina virtualmente il flusso di informazioni in entrata e in uscita dal sistema e le origini dati richieste. Vengono utilizzati il ​​diagramma di flusso dei dati, la modellazione del diagramma ER.

Progettazione fisica

La progettazione fisica si riferisce agli effettivi processi di input e output del sistema. Si concentra su come i dati vengono inseriti in un sistema, verificati, elaborati e visualizzati come output.

Produce il sistema di lavoro definendo la specifica di progetto che specifica esattamente cosa fa il sistema candidato. Si occupa di progettazione dell'interfaccia utente, progettazione dei processi e progettazione dei dati.

Consiste dei seguenti passaggi:

• Specificare il supporto di input / output, progettare il database e specificare le procedure di backup.

• Implementazione del sistema di pianificazione.

• Elaborare un piano di test e implementazione e specificare qualsiasi nuovo hardware e software.

• Aggiornamento di costi, vantaggi, date di conversione e vincoli di sistema.

Progettazione architettonica

È anche noto come progettazione di alto livello che si concentra sulla progettazione dell'architettura di sistema. Descrive la struttura e il comportamento del sistema. Definisce la struttura e la relazione tra i vari moduli del processo di sviluppo del sistema.

Design dettagliato

Segue la progettazione architettonica e si concentra sullo sviluppo di ogni modulo.

Modellazione concettuale dei dati

È la rappresentazione dei dati organizzativi che include tutte le principali entità e relazioni. Gli analisti di sistema sviluppano un modello di dati concettuale per il sistema corrente che supporta l'ambito e i requisiti per il sistema proposto.

Lo scopo principale della modellazione dei dati concettuali è acquisire quanto più significato possibile dei dati. La maggior parte delle organizzazioni oggi utilizza la modellazione concettuale dei dati utilizzando il modello ER che utilizza una notazione speciale per rappresentare quanto più significato possibile sui dati.

Modello di relazione tra entità

È una tecnica utilizzata nella progettazione di database che aiuta a descrivere la relazione tra le varie entità di un'organizzazione.

Termini usati nel modello ER

• ENTITY- Specifica elementi distinti del mondo reale in un'applicazione. Ad esempio: venditore, articolo, studente, corso, insegnanti, ecc.

• RELATIONSHIP- Sono le dipendenze significative tra entità. Ad esempio, il fornitore fornisce articoli, l'insegnante tiene corsi, quindi forniture e corso sono relazioni.

• ATTRIBUTES- Specifica le proprietà delle relazioni. Ad esempio, codice fornitore, nome studente. Simboli utilizzati nel modello ER e loro rispettivi significati -

La tabella seguente mostra i simboli utilizzati nel modello ER e il loro significato:

Simbolo	Senso
	Entità
	Entità debole
	Relazione
	Relazione di identità
	Attributi
	Attributi chiave
	Multivalore
	Attributo composito
	Attributi derivati
	Partecipazione totale di E2 a R
	Rapporto di cardinalità 1: N per E1: E2 in R

Possono esistere tre tipi di relazioni tra due set di dati: uno a uno, uno a molti e molti a molti.

Organizzazione dei file

Descrive come vengono archiviati i record all'interno di un file.

Esistono quattro metodi di organizzazione dei file:

• Serial - Le registrazioni vengono memorizzate in ordine cronologico (nell'ordine in cui vengono inserite o si verificano). Examples - Registrazione di addebiti telefonici, transazioni bancomat, code telefoniche.

• Sequential - I record vengono archiviati in base a un campo chiave che contiene un valore che identifica in modo univoco un record. Examples - Elenchi telefonici.

• Direct (relative)- Ogni record viene archiviato in base a un indirizzo fisico o alla posizione sul dispositivo. L'indirizzo viene calcolato dal valore memorizzato nel campo chiave del record. La routine randomizzata o l'algoritmo di hashing esegue la conversione.

• Indexed - I record possono essere elaborati sia in modo sequenziale che non sequenziale utilizzando gli indici.

Confronto

Accesso ai file

È possibile accedere a un file utilizzando l'accesso sequenziale o l'accesso casuale. I metodi di accesso ai file consentono ai programmi per computer di leggere o scrivere record in un file.

Accesso sequenziale

Ogni record sul file viene elaborato a partire dal primo record fino al raggiungimento della fine del file (EOF). È efficiente quando è necessario accedere a un numero elevato di record sul file in un dato momento. È possibile accedere ai dati memorizzati su un nastro (accesso sequenziale) solo in sequenza.

Accesso diretto (casuale)

I record vengono individuati conoscendo le loro posizioni fisiche o indirizzi sul dispositivo piuttosto che le loro posizioni rispetto ad altri record. È possibile accedere ai dati memorizzati su un dispositivo CD (accesso diretto) in modo sequenziale o casuale.

Tipi di file utilizzati in un sistema organizzativo

Di seguito sono riportati i tipi di file utilizzati in un sistema organizzativo:

• Master file- Contiene le informazioni correnti per un sistema. Ad esempio, file del cliente, file dello studente, elenco telefonico.

• Table file- È un tipo di file master che cambia di rado e memorizzato in un formato tabulare. Ad esempio, memorizzare il codice postale.

• Transaction file- Contiene le informazioni quotidiane generate dalle attività aziendali. Viene utilizzato per aggiornare o elaborare il file master. Ad esempio, indirizzi dei dipendenti.

• Temporary file - Viene creato e utilizzato ogni volta che è necessario un sistema.

• Mirror file- Sono gli esatti duplicati di altri file. Aiuta a ridurre al minimo il rischio di tempi di inattività nei casi in cui l'originale diventa inutilizzabile. Devono essere modificati ogni volta che viene modificato il file originale.

• Log files- Contengono copie del record principale e delle transazioni per registrare le modifiche apportate al file principale. Facilita il controllo e fornisce un meccanismo per il ripristino in caso di guasto del sistema.

• Archive files - File di backup che contengono versioni storiche di altri file.

Controllo della documentazione

La documentazione è un processo di registrazione delle informazioni per qualsiasi riferimento o scopo operativo. Aiuta utenti, manager e personale IT che lo richiedono. È importante che il documento preparato venga aggiornato regolarmente per tracciare facilmente l'avanzamento del sistema.

Dopo l'implementazione del sistema, se il sistema funziona in modo improprio, la documentazione aiuta l'amministratore a comprendere il flusso di dati nel sistema per correggere i difetti e far funzionare il sistema.

I programmatori o gli analisti di sistema di solito creano la documentazione del programma e del sistema. Gli analisti di sistema di solito sono responsabili della preparazione della documentazione per aiutare gli utenti ad apprendere il sistema. Nelle grandi aziende, un team di supporto tecnico che include redattori tecnici potrebbe assistere nella preparazione della documentazione utente e dei materiali di formazione.

Vantaggi

• Può ridurre i tempi di fermo del sistema, tagliare i costi e accelerare le attività di manutenzione.

• Fornisce la chiara descrizione del flusso formale del sistema attuale e aiuta a capire il tipo di dati di input e come l'output può essere prodotto.

• Fornisce un modo efficace ed efficiente di comunicazione tra utenti tecnici e non tecnici sul sistema.

• Facilita la formazione del nuovo utente in modo che possa facilmente comprendere il flusso del sistema.

• Aiuta l'utente a risolvere i problemi come la risoluzione dei problemi e aiuta il manager a prendere migliori decisioni finali del sistema organizzativo.

• Fornisce un migliore controllo al funzionamento interno o esterno del sistema.

Tipi di documentazione

Quando si tratta di System Design, ci sono le seguenti quattro documentazioni principali:

• Documentazione del programma
• Documentazione del sistema
• Documentazione delle operazioni
• Documentazione utente

Documentazione del programma

• Descrive gli ingressi, le uscite e la logica di elaborazione per tutti i moduli del programma.

• Il processo di documentazione del programma inizia nella fase di analisi del sistema e continua durante l'implementazione.

• Questa documentazione guida i programmatori, che costruiscono moduli ben supportati da commenti e descrizioni interni ed esterni che possono essere compresi e gestiti facilmente.

Documentazione operativa

La documentazione delle operazioni contiene tutte le informazioni necessarie per l'elaborazione e la distribuzione dell'output in linea e stampato. La documentazione delle operazioni dovrebbe essere chiara, concisa e disponibile online, se possibile.

Include le seguenti informazioni:

• Programma, analista di sistema, programmatore e identificazione del sistema.

• Pianificazione delle informazioni per l'output stampato, come report, frequenza di esecuzione e scadenze.

• File di input, origine, file di output e destinazione.

• Liste di distribuzione di posta elettronica e report.

• Moduli speciali richiesti, inclusi moduli online.

• Messaggi di errore e informativi agli operatori e procedure di riavvio.

• Istruzioni speciali, come requisiti di sicurezza.

Documentazione per l'utente

Include istruzioni e informazioni per gli utenti che interagiranno con il sistema. Ad esempio, manuali utente, guide di aiuto e tutorial. La documentazione per l'utente è preziosa per la formazione degli utenti e per scopi di riferimento. Deve essere chiaro, comprensibile e facilmente accessibile agli utenti a tutti i livelli.

Gli utenti, i proprietari di sistemi, gli analisti e i programmatori hanno tutti compiuto sforzi congiunti per sviluppare una guida per l'utente.

Una documentazione per l'utente dovrebbe includere:

• Una panoramica del sistema che descrive chiaramente tutte le principali caratteristiche, capacità e limitazioni del sistema.

• Descrizione del contenuto del documento di origine, preparazione, elaborazione e campioni.

• Panoramica delle opzioni del menu e della schermata di immissione dati, dei contenuti e delle istruzioni di elaborazione.

• Esempi di rapporti prodotti regolarmente o disponibili su richiesta dell'utente, inclusi campioni.

• Informazioni su sicurezza e audit trail.

• Spiegazione della responsabilità per requisiti di input, output o elaborazione specifici.

• Procedure per richiedere modifiche e segnalare problemi.

• Esempi di eccezioni e situazioni di errore.

• Domande frequenti (FAQ).

• Spiegazione di come ottenere aiuto e procedure per l'aggiornamento del manuale utente.

Documentazione di sistema

La documentazione del sistema funge da specifiche tecniche per l'IS e come gli obiettivi dell'IS vengono raggiunti. Utenti, gestori e proprietari di IS non devono mai fare riferimento alla documentazione del sistema. La documentazione del sistema fornisce la base per comprendere gli aspetti tecnici dell'IS quando vengono apportate modifiche.

• Descrive ogni programma all'interno dell'IS e l'intero IS stesso.

• Descrive le funzioni del sistema, il modo in cui vengono implementate, lo scopo di ciascun programma all'interno dell'intero IS rispetto all'ordine di esecuzione, le informazioni trasmesse a e dai programmi e il flusso complessivo del sistema.

• Include le voci del dizionario dei dati, i diagrammi di flusso dei dati, i modelli di oggetti, i layout dello schermo, i documenti di origine e la richiesta di sistema che ha avviato il progetto.

• La maggior parte della documentazione del sistema viene preparata durante le fasi di analisi e progettazione del sistema.

• Durante l'implementazione dei sistemi, un analista deve rivedere la documentazione del sistema per verificare che sia completa, accurata e aggiornata e includa eventuali modifiche apportate durante il processo di implementazione.

Strategia top-down

La strategia top-down utilizza l'approccio modulare per sviluppare il design di un sistema. Si chiama così perché parte dal modulo superiore o di livello più alto e si sposta verso i moduli di livello più basso.

In questa tecnica, viene identificato il modulo di livello più alto o il modulo principale per lo sviluppo del software. Il modulo principale è suddiviso in diversi sottomoduli o segmenti più piccoli e più semplici in base al compito svolto da ciascun modulo. Quindi, ogni sottomodulo è ulteriormente suddiviso in diversi sottomoduli di livello inferiore successivo. Questo processo di divisione di ogni modulo in più sottomoduli continua fino a quando i moduli di livello più basso, che non possono essere ulteriormente suddivisi, non vengono identificati.

Strategia dal basso verso l'alto

La strategia Bottom-Up segue l'approccio modulare per sviluppare il design del sistema. Si chiama così perché parte dai moduli di livello inferiore o più elementari e si sposta verso i moduli di livello più alto.

In questa tecnica,

• Vengono identificati i moduli al livello più elementare o più basso.

• Questi moduli vengono quindi raggruppati in base alla funzione svolta da ciascun modulo per formare i successivi moduli di livello superiore.

• Quindi, questi moduli vengono ulteriormente combinati per formare i successivi moduli di livello superiore.

• Questo processo di raggruppamento di diversi moduli più semplici per formare moduli di livello superiore continua fino a quando non viene raggiunto il modulo principale del processo di sviluppo del sistema.

Design strutturato

La progettazione strutturata è una metodologia basata sul flusso di dati che aiuta a identificare l'input e l'output del sistema di sviluppo. L'obiettivo principale del design strutturato è ridurre al minimo la complessità e aumentare la modularità di un programma. Il design strutturato aiuta anche a descrivere gli aspetti funzionali del sistema.

Nella progettazione strutturata, le specifiche del sistema fungono da base per rappresentare graficamente il flusso di dati e la sequenza dei processi coinvolti in uno sviluppo software con l'aiuto di DFD. Dopo aver sviluppato i DFD per il sistema software, il passaggio successivo consiste nello sviluppare il grafico della struttura.

Modularizzazione

La progettazione strutturata divide il programma in moduli piccoli e indipendenti. Questi sono organizzati dall'alto verso il basso con i dettagli mostrati in basso.

Pertanto, il design strutturato utilizza un approccio chiamato Modularizzazione o scomposizione per ridurre al minimo la complessità e per gestire il problema suddividendolo in segmenti più piccoli.

Advantages

• Le interfacce critiche vengono prima testate.
• Fornisce astrazione.
• Consente a più programmatori di lavorare contemporaneamente.
• Consente il riutilizzo del codice.
• Fornisce controllo e migliora il morale.
• Rende più facile l'identificazione della struttura.

Grafici strutturati

I grafici strutturati sono uno strumento consigliato per progettare sistemi modulari top down che definiscono i vari moduli di sviluppo del sistema e la relazione tra ogni modulo. Mostra il modulo di sistema e la loro relazione tra di loro.

Consiste in un diagramma costituito da caselle rettangolari che rappresentano i moduli, frecce di collegamento o linee.

• Control Module - È un modulo di livello superiore che dirige i moduli di livello inferiore, chiamati subordinate modules.

• Library Module - È un modulo riutilizzabile e può essere richiamato da più di un punto nel grafico.

Abbiamo due diversi approcci per progettare un grafico strutturato:

• Transform-Centered Structured Charts - Vengono utilizzati quando tutte le transazioni seguono lo stesso percorso.

• Transaction–Centered Structured Charts - Vengono utilizzati quando tutte le transazioni non seguono lo stesso percorso.

Obiettivi dell'utilizzo dei diagrammi di flusso della struttura

• Per incoraggiare un design top-down.

• Supportare il concetto di moduli e identificare i moduli appropriati.

• Per mostrare le dimensioni e la complessità del sistema.

• Per identificare il numero di funzioni e moduli facilmente identificabili all'interno di ciascuna funzione.

• Descrivere se ciascuna funzione identificabile è un'entità gestibile o deve essere suddivisa in componenti più piccole.

Fattori che influenzano la complessità del sistema

Per sviluppare una buona qualità del software di sistema, è necessario sviluppare un buon design. Pertanto, l'obiettivo principale durante lo sviluppo del design del sistema è la qualità del design del software. Un design software di buona qualità è quello che riduce al minimo la complessità e il costo nello sviluppo del software.

I due concetti importanti relativi allo sviluppo del sistema che aiutano a determinare la complessità di un sistema sono coupling e cohesion.

Accoppiamento

L'accoppiamento è la misura dell'indipendenza dei componenti. Definisce il grado di dipendenza di ogni modulo di sviluppo del sistema dall'altro. In pratica, ciò significa che più forte è l'accoppiamento tra i moduli in un sistema, più difficile è implementare e mantenere il sistema.

Ogni modulo dovrebbe avere un'interfaccia semplice e pulita con altri moduli e che il numero minimo di elementi di dati dovrebbe essere condiviso tra i moduli.

Alto accoppiamento

Questi tipi di sistemi hanno interconnessioni con unità di programma dipendenti l'una dall'altra. Le modifiche a un sottosistema comportano un impatto elevato sull'altro sottosistema.

Basso accoppiamento

Questi tipi di sistemi sono costituiti da componenti indipendenti o quasi indipendenti. Una modifica in un sottosistema non influisce su nessun altro sottosistema.

Misure di accoppiamento

• Content Coupling - Quando un componente ne modifica effettivamente un altro, il componente modificato dipende completamente dalla modifica di uno.

• Common Coupling - Quando la quantità di accoppiamento viene ridotta in qualche modo organizzando la progettazione del sistema in modo che i dati siano accessibili da un archivio dati comune.

• Control Coupling - Quando un componente passa parametri per controllare l'attività di un altro componente.

• Stamp Coupling - Quando le strutture dati vengono utilizzate per passare informazioni da un componente a un altro.

• Data Coupling - Quando vengono trasmessi solo dati, i componenti sono collegati da questo accoppiamento.

Coesione

La coesione è la misura della vicinanza del rapporto tra i suoi componenti. Definisce la quantità di dipendenza dei componenti di un modulo l'uno dall'altro. In pratica, ciò significa che il progettista di sistemi deve garantire che:

• Non suddividono i processi essenziali in moduli frammentati.

• Non riuniscono processi non correlati rappresentati come processi sul DFD in moduli privi di significato.

I moduli migliori sono quelli funzionalmente coesi. I moduli peggiori sono quelli che sono coincidenti per coincidenza.

Il peggior grado di coesione

La coesione coincidente si trova in un componente le cui parti non sono correlate a un altro.

• Logical Cohesion - È il punto in cui diverse funzioni o elementi di dati correlati logicamente vengono inseriti nello stesso componente.

• Temporal Cohesion - È quando un componente utilizzato per inizializzare un sistema o impostare variabili esegue diverse funzioni in sequenza, ma le funzioni sono correlate dalla temporizzazione coinvolta.

• Procedurally Cohesion - È quando le funzioni sono raggruppate in un componente solo per garantire questo ordine.

• Sequential Cohesion - È quando l'output da una parte di un componente è l'input per la parte successiva di esso.

Input Design

In un sistema informativo, l'input è il dato grezzo che viene elaborato per produrre l'output. Durante la progettazione degli input, gli sviluppatori devono considerare i dispositivi di input come PC, MICR, OMR, ecc.

Pertanto, la qualità dell'input del sistema determina la qualità dell'output del sistema. I moduli di input e le schermate ben progettati hanno le seguenti proprietà:

• Dovrebbe servire a uno scopo specifico in modo efficace come l'archiviazione, la registrazione e il recupero delle informazioni.

• Assicura il corretto completamento con precisione.

• Dovrebbe essere facile da riempire e diretto.

• Dovrebbe concentrarsi sull'attenzione, sulla coerenza e sulla semplicità dell'utente.

• Tutti questi obiettivi sono ottenuti utilizzando la conoscenza dei principi di progettazione di base riguardanti:

  • Quali sono gli input necessari per il sistema?

  • In che modo gli utenti finali rispondono ai diversi elementi di moduli e schermate.

Obiettivi per Input Design

Gli obiettivi dell'input design sono:

• Progettare l'immissione dei dati e le procedure di immissione

• Per ridurre il volume di ingresso

• Progettare documenti di origine per l'acquisizione dei dati o ideare altri metodi di acquisizione dei dati

• Per progettare record di dati di input, schermate di immissione dati, schermate dell'interfaccia utente, ecc.

• Utilizzare controlli di convalida e sviluppare controlli di input efficaci.

Metodi di immissione dei dati

È importante progettare metodi di immissione dei dati appropriati per evitare errori durante l'immissione dei dati. Questi metodi dipendono dal fatto che i dati vengano inseriti dai clienti nei moduli manualmente e successivamente inseriti dagli operatori di data entry, oppure i dati siano inseriti direttamente dagli utenti sui PC.

Un sistema dovrebbe impedire all'utente di commettere errori:

• Design chiaro della forma lasciando spazio sufficiente per scrivere in modo leggibile.
• Istruzioni chiare per compilare il modulo.
• Design chiaro della forma.
• Riduzione dei colpi chiave.
• Feedback immediato sugli errori.

Alcuni dei metodi di immissione dei dati più diffusi sono:

• Metodo di immissione in batch (metodo di immissione dei dati offline)
• Metodo di immissione dei dati online
• Moduli leggibili da computer
• Inserimento dati interattivo

Controlli di integrità dell'input

I controlli di integrità dell'input includono una serie di metodi per eliminare gli errori di input comuni da parte degli utenti finali. Includono anche controlli sul valore dei singoli campi; sia per il formato che per la completezza di tutti gli input.

Gli audit trail per l'immissione dei dati e altre operazioni di sistema vengono creati utilizzando i registri delle transazioni che forniscono una registrazione di tutte le modifiche introdotte nel database per fornire sicurezza e mezzi di ripristino in caso di qualsiasi errore.

Progettazione di output

La progettazione dell'output è il compito più importante di qualsiasi sistema. Durante la progettazione dell'output, gli sviluppatori identificano il tipo di output necessari e prendono in considerazione i controlli di output necessari e i layout dei report prototipo.

Obiettivi dell'output design

Gli obiettivi dell'input design sono:

• Sviluppare un design di output che serva allo scopo previsto ed elimina la produzione di output indesiderato.

• Sviluppare il design dell'output che soddisfi i requisiti degli utenti finali.

• Per fornire la quantità appropriata di output.

• Per formare l'output nel formato appropriato e indirizzarlo alla persona giusta.

• Rendere disponibile l'output in tempo per prendere buone decisioni.

Esaminiamo ora vari tipi di output:

Uscite esterne

I produttori creano e progettano output esterni per le stampanti. Gli output esterni consentono al sistema di lasciare le azioni di attivazione da parte dei destinatari o di confermare le azioni ai destinatari.

Alcuni degli output esterni sono progettati come output di inversione di tendenza, che vengono implementati come un modulo e rientrano nel sistema come input.

Uscite interne

Gli output interni sono presenti all'interno del sistema e utilizzati dagli utenti finali e dai gestori. Supportano la direzione nel processo decisionale e nel reporting.

Esistono tre tipi di report prodotti dalle informazioni di gestione:

• Detailed Reports - Contengono informazioni attuali che non hanno quasi nessun filtro o restrizione generata per assistere la pianificazione e il controllo della gestione.

• Summary Reports - Contengono tendenze e potenziali problemi categorizzati e riepilogati generati per i manager che non desiderano dettagli.

• Exception Reports - Contengono eccezioni, dati filtrati per alcune condizioni o standard prima di presentarli al manager, come informazioni.

Controlli di integrità dell'output

I controlli di integrità dell'output includono codici di instradamento per identificare il sistema ricevente e messaggi di verifica per confermare la corretta ricezione dei messaggi gestiti dal protocollo di rete.

I rapporti stampati o in formato schermo dovrebbero includere una data / ora per la stampa del rapporto e dei dati. I rapporti a più pagine contengono il titolo o la descrizione del rapporto e l'impaginazione. I moduli prestampati di solito includono un numero di versione e una data di validità.

Progettazione di moduli

Sia i moduli che i report sono il prodotto della progettazione di input e output e sono documenti commerciali costituiti da dati specificati. La differenza principale è che i moduli forniscono i campi per l'immissione dei dati, ma i report vengono utilizzati esclusivamente per la lettura. Ad esempio, moduli d'ordine, domanda di assunzione e credito, ecc.

• Durante la progettazione del modulo, i progettisti dovrebbero sapere:

  • chi li utilizzerà

  • dove sarebbero stati consegnati

  • lo scopo del modulo o del report

• Durante la progettazione del modulo, gli strumenti di progettazione automatizzata migliorano la capacità dello sviluppatore di prototipare moduli e report e presentarli agli utenti finali per la valutazione.

Obiettivi di una buona forma progettuale

Una buona progettazione del modulo è necessaria per garantire quanto segue:

• Per mantenere lo schermo semplice fornendo una sequenza corretta, informazioni e didascalie chiare.

• Per soddisfare lo scopo previsto utilizzando moduli appropriati.

• Per garantire la compilazione del modulo con precisione.

• Per mantenere i moduli attraenti utilizzando icone, video inverso o cursori lampeggianti, ecc.

• Per facilitare la navigazione.

Tipi di moduli

Flat Forms

• È un modulo in singola copia preparato manualmente o da una macchina e stampato su carta. Per ulteriori copie dell'originale, vengono inserite carte carbone tra le copie.

• È una forma più semplice ed economica per progettare, stampare e riprodurre, che utilizza meno volume.

Unit Set/Snap out Forms

• Si tratta di carte con carboni attivi una tantum intervallati in set di unità per uso scritto a mano o meccanico.

• I carboni possono essere blu o neri, di media intensità di grado standard. Generalmente, i carboni blu sono i migliori per i moduli scritti a mano mentre i carboni neri sono i migliori per l'uso a macchina.

Continuous strip/Fanfold Forms

• Si tratta di più moduli unitari uniti in una striscia continua con perforazioni tra ciascuna coppia di moduli.

• È un metodo meno costoso per l'utilizzo di grandi volumi.

No Carbon Required (NCR) Paper

• Usano carte autocopianti che hanno due rivestimenti chimici (capsule), uno sulla faccia e l'altro sul retro di un foglio di carta.

• Quando viene applicata la pressione, le due capsule interagiscono e creano un'immagine.

Il sistema software deve essere controllato per il comportamento previsto e la direzione del progresso in ogni fase di sviluppo per evitare la duplicazione di sforzi, superamenti di tempo e costi e per garantire il completamento del sistema entro il tempo stabilito. comportamento previsto e direzione del progresso in ogni fase di sviluppo per evitare la duplicazione degli sforzi, il superamento dei tempi e dei costi e per assicurare il completamento del sistema entro il tempo stabilito.

Il test del sistema e la garanzia della qualità vengono in aiuto per il controllo del sistema. Include:

• Qualità a livello di prodotto (test)
• Qualità a livello di processo.

Esaminiamoli brevemente:

Test

Il test è il processo o l'attività che controlla la funzionalità e la correttezza del software in base ai requisiti utente specificati al fine di migliorare la qualità e l'affidabilità del sistema. È un approccio costoso, dispendioso in termini di tempo e critico nello sviluppo del sistema che richiede un'adeguata pianificazione del processo di test complessivo.

Un test di successo è quello che trova gli errori. Esegue il programma con l'intenzione esplicita di trovare errori, ovvero di far fallire il programma. È un processo di valutazione del sistema con l'intenzione di creare un sistema forte e si concentra principalmente sulle aree deboli del sistema o del software.

Caratteristiche del test di sistema

Il test del sistema inizia a livello di modulo e procede verso l'integrazione dell'intero sistema software. Diverse tecniche di test vengono utilizzate in momenti diversi durante il test del sistema. È condotto dallo sviluppatore per piccoli progetti e da gruppi di test indipendenti per grandi progetti.

Fasi del test di sistema

Le seguenti fasi sono coinvolte nel test:

Test Strategy

È una dichiarazione che fornisce informazioni sui vari livelli, metodi, strumenti e tecniche utilizzati per testare il sistema. Dovrebbe soddisfare tutte le esigenze di un'organizzazione.

Test Plan

Fornisce un piano per testare il sistema e verifica che il sistema sottoposto a test soddisfi tutte le specifiche di progettazione e funzionali. Il piano di test fornisce le seguenti informazioni:

• Obiettivi di ogni fase del test
• Approcci e strumenti utilizzati per i test
• Responsabilità e tempo richiesto per ogni attività di test
• Disponibilità di strumenti, strutture e librerie di test
• Procedure e standard richiesti per la pianificazione e l'esecuzione dei test
• Fattori responsabili del completamento con successo del processo di test

Test Case Design

• Per ogni modulo del sistema da testare viene identificato un numero di casi di test.

• Ciascun caso di test specificherà come deve essere testata l'implementazione di un particolare requisito o decisione di progettazione ei criteri per il successo del test.

• I casi di test insieme al piano di test sono documentati come parte di un documento di specifica del sistema o in un documento separato chiamato test specification o test description.

Test Procedures

Consiste nei passaggi che dovrebbero essere seguiti per eseguire ciascuno dei casi di test. Queste procedure sono specificate in un documento separato chiamato specifica della procedura di test. Questo documento specifica anche eventuali requisiti e formati speciali per la segnalazione del risultato del test.

Test Result Documentation

Il file dei risultati del test contiene brevi informazioni sul numero totale di casi di test eseguiti, il numero di errori e la natura degli errori. Questi risultati vengono quindi valutati rispetto ai criteri nelle specifiche del test per determinare il risultato complessivo del test.

Tipi di test

I test possono essere di vari tipi e vengono condotti diversi tipi di test a seconda del tipo di bug che si cerca di scoprire -

Test unitario

Conosciuto anche come test di programma, è un tipo di test in cui l'analista verifica o si concentra su ciascun programma o modulo in modo indipendente. Viene eseguito con l'intenzione di eseguire almeno una volta ogni istruzione del modulo.

• Nei test unitari, non è possibile garantire l'accuratezza del programma ed è difficile condurre in dettaglio i test di varie combinazioni di input.

• Identifica gli errori massimi in un programma rispetto ad altre tecniche di test.

Test d'integrazione

In Integration Testing, l'analista testa più moduli che lavorano insieme. Viene utilizzato per trovare discrepanze tra il sistema e il suo obiettivo originale, le specifiche attuali e la documentazione del sistema.

• Qui gli analisti cercano di trovare aree in cui i moduli sono stati progettati con specifiche diverse per lunghezza dati, tipo e nome elemento dati.

• Verifica che le dimensioni dei file siano adeguate e che gli indici siano stati creati correttamente.

Test funzionali

Il test funzionale determina se il sistema funziona correttamente secondo le sue specifiche e la relativa documentazione degli standard. Il test funzionale inizia in genere con l'implementazione del sistema, che è molto critico per il successo del sistema.

Il test funzionale è diviso in due categorie:

• Positive Functional Testing - Si tratta di testare il sistema con input validi per verificare che gli output prodotti siano corretti.

• Negative Functional Testing - Si tratta di testare il software con input non validi e condizioni operative indesiderate.

Regole per il test del sistema

Per eseguire correttamente il test del sistema, è necessario seguire le regole fornite:

• Il test dovrebbe essere basato sui requisiti dell'utente.

• Prima di scrivere script di test, è necessario comprendere a fondo la logica aziendale.

• Il piano di test dovrebbe essere fatto il prima possibile.

• Il test dovrebbe essere eseguito da terze parti.

• Dovrebbe essere eseguito su software statico.

• Il test dovrebbe essere eseguito per condizioni di input valide e non valide.

• I test dovrebbero essere riesaminati ed esaminati per ridurre i costi.

• Sia i test statici che quelli dinamici dovrebbero essere condotti sul software.

• Deve essere eseguita la documentazione dei casi di test e dei risultati dei test.

Garanzia di qualità

È la revisione del sistema o dei prodotti software e la relativa documentazione per garantire che il sistema soddisfi i requisiti e le specifiche.

• Scopo del controllo qualità è fornire fiducia ai clienti attraverso la consegna costante del prodotto secondo le specifiche.

• Il Software Quality Assurance (SQA) è una tecnica che include procedure e strumenti applicati dai professionisti del software per garantire che il software soddisfi lo standard specificato per l'uso e le prestazioni previsti.

• L'obiettivo principale di SQA è fornire all'amministrazione una visibilità adeguata e accurata del progetto software e del prodotto sviluppato.

• Esamina e controlla il prodotto software e le sue attività durante il ciclo di vita dello sviluppo del sistema.

Obiettivi della garanzia di qualità

Gli obiettivi della conduzione della garanzia di qualità sono i seguenti:

• Monitorare il processo di sviluppo del software e il software finale sviluppato.

• Per garantire se il progetto software sta implementando gli standard e le procedure stabilite dalla direzione.

• Informare gruppi e individui sulle attività SQA e sui risultati di queste attività.

• Per garantire che i problemi, che non vengono risolti all'interno del software, vengano affrontati dal management superiore.

• Per identificare le carenze nel prodotto, nel processo o negli standard e risolverle.

Livelli di garanzia della qualità

Esistono diversi livelli di QA e test che devono essere eseguiti per certificare un prodotto software.

Level 1 − Code Walk-through

A questo livello, il software offline viene esaminato o verificato per eventuali violazioni delle regole di codifica ufficiali. In generale, l'accento è posto sull'esame della documentazione e sul livello dei commenti nel codice.

Level 2 − Compilation and Linking

A questo livello, viene verificato che il software possa compilare e collegare tutte le piattaforme ei sistemi operativi ufficiali.

Level 3 − Routine Running

A questo livello, viene verificato che il software possa funzionare correttamente in una varietà di condizioni come un certo numero di eventi e dimensioni di eventi piccoli e grandi, ecc.

Level 4 − Performance test

A questo livello finale, viene verificato che le prestazioni del software soddisfino il livello di prestazioni specificato in precedenza.

L'implementazione è un processo per garantire che il sistema informativo sia operativo. Si tratta di:

• Costruire un nuovo sistema da zero
• Costruire un nuovo sistema da quello esistente.

L'implementazione consente agli utenti di assumerne il funzionamento per l'uso e la valutazione. Si tratta di addestrare gli utenti a gestire il sistema e pianificare una conversione senza problemi.

Formazione

Il personale del sistema deve sapere in dettaglio quali saranno i loro ruoli, come possono utilizzare il sistema e cosa farà o non farà. Il successo o il fallimento di sistemi ben progettati e tecnicamente eleganti può dipendere dal modo in cui vengono azionati e utilizzati.

Operatori dei sistemi di formazione

Gli operatori dei sistemi devono essere adeguatamente formati in modo da poter gestire tutte le operazioni possibili, sia ordinarie che straordinarie. Gli operatori dovrebbero essere addestrati su quali malfunzionamenti comuni possono verificarsi, come riconoscerli e quali misure intraprendere quando si verificano.

La formazione prevede la creazione di elenchi di risoluzione dei problemi per identificare possibili problemi e rimedi per essi, nonché i nomi e i numeri di telefono delle persone da contattare in caso di problemi imprevisti o insoliti.

La formazione implica anche la familiarizzazione con le procedure di esecuzione, che implica l'elaborazione della sequenza di attività necessarie per utilizzare un nuovo sistema.

Formazione per gli utenti

• La formazione degli utenti finali è una parte importante dello sviluppo del sistema informativo basato su computer, che deve essere fornita ai dipendenti per consentire loro di risolvere i propri problemi.

• La formazione degli utenti comprende come utilizzare l'apparecchiatura, risolvere il problema del sistema, determinare se un problema che si è verificato è causato dall'apparecchiatura o dal software.

• La maggior parte della formazione degli utenti si occupa del funzionamento del sistema stesso. I corsi di formazione devono essere progettati per aiutare l'utente con una rapida mobilitazione per l'organizzazione.

Linee guida per la formazione

• Stabilire obiettivi misurabili
• Utilizzo di metodi di formazione appropriati
• Selezione di siti di formazione adeguati
• Impiegando materiali di formazione comprensibili

Metodi di allenamento

Formazione con istruttore

Coinvolge sia i formatori che i tirocinanti, che devono incontrarsi nello stesso momento, ma non necessariamente nello stesso luogo. La sessione di formazione potrebbe essere individuale o collaborativa. È di due tipi:

Virtual Classroom

In questa formazione, i formatori devono incontrare i partecipanti allo stesso tempo, ma non è necessario che si trovino nello stesso luogo. Gli strumenti principali utilizzati qui sono: videoconferenza, strumenti di chat relay su Internet basati su testo o pacchetti di realtà virtuale, ecc.

Normal Classroom

I formatori devono incontrare i tirocinanti nello stesso momento e nello stesso luogo. Gli strumenti principali utilizzati qui sono lavagna, lavagne luminose, proiettore LCD, ecc.

Formazione personalizzata

Coinvolge sia i formatori che i tirocinanti, che non hanno bisogno di incontrarsi nello stesso luogo o nello stesso momento. I tirocinanti apprendono le abilità da soli accedendo ai corsi a loro piacimento. È di due tipi:

Multimedia Training

In questa formazione, i corsi sono presentati in formato multimediale e memorizzati su CD-ROM. Riduce al minimo i costi per lo sviluppo di un corso di formazione interno senza l'assistenza di programmatori esterni.

Web-based Training

In questa formazione, i corsi sono spesso presentati in formato ipermediale e sviluppati per supportare Internet e intranet. Fornisce formazione just-in-time per gli utenti finali e consente all'organizzazione di adattare i requisiti di formazione.

Conversione

È un processo di migrazione dal vecchio sistema a quello nuovo. Fornisce un approccio comprensibile e strutturato per migliorare la comunicazione tra la direzione e il team di progetto.

Piano di conversione

Contiene la descrizione di tutte le attività che devono avvenire durante l'implementazione del nuovo sistema e metterlo in funzione. Anticipa possibili problemi e soluzioni per affrontarli.

Comprende le seguenti attività:

• Assegna un nome a tutti i file per le conversioni.
• Identificazione dei requisiti di dati per sviluppare nuovi file durante la conversione.
• Elenco di tutti i nuovi documenti e procedure richiesti.
• Identificare i controlli da utilizzare in ogni attività.
• Identificare la responsabilità della persona per ogni attività.
• Verifica delle pianificazioni di conversione.

Metodi di conversione

I quattro metodi di conversione sono:

• Conversione parallela
• Conversione completa diretta
• Approccio pilota
• Metodo Phase-In

Metodo	Descrizione	Vantaggi	Svantaggi
Conversione parallela	I sistemi vecchi e nuovi vengono utilizzati contemporaneamente.	Fornisce fallback quando il nuovo sistema fallisce. Offre la massima sicurezza e, in definitiva, il test del nuovo sistema.	Causa il superamento dei costi. Il nuovo sistema potrebbe non avere un percorso equo.
Conversione completa diretta	Il nuovo sistema viene implementato e il vecchio sistema viene sostituito completamente.	Forza gli utenti a far funzionare il nuovo sistema Beneficio immediato di nuovi metodi e controlli.	Nessun ripiego se sorgono problemi con il nuovo sistema Richiede una pianificazione più attenta
Approccio pilota	Supporta un approccio graduale che implementa gradualmente il sistema su tutti gli utenti	Consente l'addestramento e l'installazione senza un utilizzo non necessario delle risorse. Evita grandi imprevisti dalla gestione del rischio.	Una fase a lungo termine causa un problema se la conversione va bene o meno.
Metodo Phase-In	Versione funzionante del sistema implementata in una parte dell'organizzazione in base al feedback, viene installata in tutta l'organizzazione da sola o fase per fase.	Fornisce esperienza e test di linea prima dell'implementazione Quando il nuovo sistema preferito implica una nuova tecnologia o drastici cambiamenti nelle prestazioni.	Dà l'impressione che il vecchio sistema sia errato e non sia affidabile.

Conversione di file

È un processo di conversione di un formato di file in un altro. Ad esempio, il file in formato WordPerfect può essere convertito in Microsoft Word.

Per una conversione di successo, è necessario un piano di conversione, che include:

• Conoscenza del sistema target e comprensione del sistema attuale
• Teamwork
• Metodi automatizzati, test e operazioni parallele
• Supporto continuo per la correzione dei problemi
• Aggiornamento di sistemi / documentazione utente, ecc

Molte applicazioni popolari supportano l'apertura e il salvataggio in altri formati di file dello stesso tipo. Ad esempio, Microsoft Word può aprire e salvare file in molti altri formati di elaborazione testi.

Revisione della valutazione post-implementazione (PIER)

PIER è uno strumento o un approccio standard per valutare i risultati del progetto e determinare se il progetto sta producendo i benefici attesi per i processi, prodotti o servizi. Consente all'utente di verificare che il progetto o il sistema abbia raggiunto il risultato desiderato entro il periodo di tempo specificato e il costo pianificato.

PIER garantisce che il progetto abbia raggiunto i suoi obiettivi valutando i processi di sviluppo e gestione del progetto.

Obiettivi di PIER

Gli obiettivi di avere un PIER sono i seguenti:

• Per determinare il successo di un progetto rispetto ai costi, ai benefici e alle tempistiche previsti.

• Identificare le opportunità per aggiungere ulteriore valore al progetto.

• Per determinare i punti di forza e di debolezza del progetto per riferimento futuro e azioni appropriate.

• Fornire raccomandazioni sul futuro del progetto perfezionando le tecniche di stima dei costi.

I seguenti membri del personale dovrebbero essere inclusi nel processo di revisione:

• Team di progetto e gestione
• Personale utente
• Staff di gestione strategica
• Utenti esterni

Manutenzione / miglioramento del sistema

Manutenzione significa riportare qualcosa alle sue condizioni originali. Miglioramento significa aggiungere, modificare il codice per supportare i cambiamenti nelle specifiche dell'utente. La manutenzione del sistema conforma il sistema ai suoi requisiti originali e il miglioramento si aggiunge alla capacità del sistema incorporando nuovi requisiti.

Pertanto, la manutenzione modifica il sistema esistente, il miglioramento aggiunge funzionalità al sistema esistente e lo sviluppo sostituisce il sistema esistente. È una parte importante dello sviluppo del sistema che include le attività che correggono gli errori nella progettazione e nell'implementazione del sistema, aggiorna i documenti e verifica i dati.

Tipi di manutenzione

La manutenzione del sistema può essere classificata in tre tipi:

• Corrective Maintenance - Consente all'utente di eseguire la riparazione e la correzione dei problemi rimanenti.

• Adaptive Maintenance - Consente all'utente di sostituire le funzioni dei programmi.

• Perfective Maintenance - Consente all'utente di modificare o migliorare i programmi in base alle esigenze degli utenti e alle mutevoli esigenze.

Audit di sistema

È un'indagine per esaminare le prestazioni di un sistema operativo. Gli obiettivi della conduzione di un audit di sistema sono i seguenti:

• Per confrontare le prestazioni effettive e pianificate.

• Verificare che gli obiettivi di sistema dichiarati siano ancora validi nell'ambiente attuale.

• Valutare il raggiungimento degli obiettivi dichiarati.

• Per garantire l'affidabilità delle informazioni finanziarie e di altro tipo basate su computer.

• Per garantire che tutti i record siano inclusi durante l'elaborazione.

• Per garantire la protezione dalle frodi.

Audit dell'utilizzo del sistema informatico

I revisori del trattamento dei dati verificano l'utilizzo del sistema informatico al fine di controllarlo. L'auditor necessita dei dati di controllo ottenuti dal sistema informatico stesso.

Il revisore del sistema

Il ruolo dell'auditor inizia nella fase iniziale dello sviluppo del sistema in modo che il sistema risultante sia sicuro. Descrive un'idea di utilizzo del sistema che può essere registrato che aiuta nella pianificazione del carico e nella decisione sulle specifiche hardware e software. Fornisce un'indicazione di un uso saggio del sistema informatico e di un possibile uso improprio del sistema.

Prova di revisione

Una prova di controllo o un registro di controllo è un record di sicurezza che comprende chi ha avuto accesso a un sistema informatico e quali operazioni vengono eseguite durante un determinato periodo di tempo. Le prove di audit vengono utilizzate per tracciare dettagliatamente come sono cambiati i dati sul sistema.

Fornisce prove documentali di varie tecniche di controllo a cui è soggetta una transazione durante l'elaborazione. Le prove di audit non esistono indipendentemente. Sono effettuati come parte della contabilità per il recupero delle transazioni perse.

Metodi di audit

L'audit può essere eseguito in due modi diversi:

Auditing intorno al computer

• Prendi input di esempio e applica manualmente le regole di elaborazione.
• Confronta le uscite con le uscite del computer.

Auditing tramite il computer

• Stabilire una sperimentazione di audit che consenta di esaminare i risultati intermedi selezionati.
• I totali di controllo forniscono controlli intermedi.

Considerazioni sull'audit

Le considerazioni di audit esaminano i risultati dell'analisi utilizzando sia le narrazioni che i modelli per identificare i problemi causati da funzioni fuori posto, processi o funzioni divisi, flussi di dati interrotti, dati mancanti, elaborazione ridondante o incompleta e opportunità di automazione non affrontate.

Le attività in questa fase sono le seguenti:

• Identificazione degli attuali problemi ambientali
• Identificazione delle cause del problema
• Individuazione di soluzioni alternative
• Valutazione e analisi di fattibilità di ogni soluzione
• Selezione e raccomandazione della soluzione più pratica e appropriata
• Stima dei costi di progetto e analisi costi-benefici

Sicurezza

La sicurezza del sistema si riferisce alla protezione del sistema da furti, accesso e modifiche non autorizzati e danni accidentali o involontari. Nei sistemi informatici, la sicurezza implica la protezione di tutte le parti del sistema informatico che include dati, software e hardware. La sicurezza dei sistemi include la privacy e l'integrità del sistema.

• System privacy si occupa di proteggere i sistemi delle persone dall'accesso e dall'utilizzo senza il permesso / la conoscenza delle persone interessate.

• System integrity si occupa della qualità e dell'affidabilità dei dati grezzi e di quelli elaborati nel sistema.

Misure di controllo

Esistono varie misure di controllo che possono essere classificate come segue:

Backup

• Backup regolare dei database giornaliero / settimanale a seconda della criticità temporale e delle dimensioni.

• Backup incrementale a intervalli più brevi.

• Copie di backup conservate in una posizione remota sicura, particolarmente necessaria per il ripristino di emergenza.

• I sistemi duplicati vengono eseguiti e tutte le transazioni vengono replicate se si tratta di un sistema molto critico e non può tollerare alcuna interruzione prima dell'archiviazione su disco.

Controllo dell'accesso fisico alle strutture

• Serrature fisiche e autenticazione biometrica. Ad esempio, impronte digitali
• Carte d'identità o tessere d'ingresso controllate dal personale di sicurezza.
• Identificazione di tutte le persone che leggono o modificano i dati e registrarli in un file.

Utilizzo del controllo logico o software

• Sistema di password.
• Crittografia di dati / programmi sensibili.
• Formazione dei dipendenti sulla cura / gestione dei dati e sulla sicurezza.
• Software antivirus e protezione firewall durante la connessione a Internet.

Analisi del rischio

Un rischio è la possibilità di perdere qualcosa di valore. L'analisi dei rischi inizia con la pianificazione di un sistema sicuro identificando la vulnerabilità del sistema e l'impatto di questo. Viene quindi elaborato il piano per gestire il rischio e far fronte al disastro. È fatto per accedere alla probabilità di possibili disastri e al loro costo.

L'analisi dei rischi è un lavoro di squadra di esperti con background diversi come prodotti chimici, errori umani e apparecchiature di processo.

I seguenti passaggi devono essere seguiti durante lo svolgimento dell'analisi dei rischi:

• Identificazione di tutti i componenti del sistema informatico.

• Identificazione di tutte le minacce e i pericoli che ciascuno dei componenti deve affrontare.

• Quantificare i rischi, ovvero valutare la perdita nel caso in cui le minacce diventino realtà.

Analisi dei rischi - Fasi principali

Poiché i rischi o le minacce stanno cambiando e anche la perdita potenziale sta cambiando, la gestione del rischio dovrebbe essere eseguita periodicamente dai senior manager.

La gestione del rischio è un processo continuo e prevede i seguenti passaggi:

• Individuazione delle misure di sicurezza.

• Calcolo del costo di attuazione delle misure di sicurezza.

• Confronto del costo delle misure di sicurezza con la perdita e la probabilità di minacce.

• Selezione e implementazione delle misure di sicurezza.

• Revisione dell'attuazione delle misure di sicurezza.

Nell'approccio orientato agli oggetti, l'attenzione si concentra sull'acquisizione della struttura e del comportamento dei sistemi informativi in ​​piccoli moduli che combinano sia dati che processi. L'obiettivo principale della progettazione orientata agli oggetti (OOD) è migliorare la qualità e la produttività dell'analisi e della progettazione del sistema rendendola più utilizzabile.

Nella fase di analisi, i modelli OO vengono utilizzati per colmare il divario tra problema e soluzione. Funziona bene in situazioni in cui i sistemi sono sottoposti a progettazione, adattamento e manutenzione continui. Identifica gli oggetti nel dominio del problema, classificandoli in termini di dati e comportamento.

Il modello OO è vantaggioso nei seguenti modi:

• Facilita le modifiche al sistema a basso costo.

• Promuove il riutilizzo dei componenti.

• Semplifica il problema dell'integrazione dei componenti per configurare un sistema di grandi dimensioni.

• Semplifica la progettazione di sistemi distribuiti.

Elementi di sistema orientato agli oggetti

Esaminiamo le caratteristiche del sistema OO -

• Objects- Un oggetto è qualcosa che esiste nel dominio del problema e può essere identificato dai dati (attributo) o dal comportamento. Tutte le entità tangibili (studente, paziente) e alcune entità intangibili (conto bancario) sono modellate come oggetti.

• Attributes - Descrivono le informazioni sull'oggetto.

• Behavior- Specifica cosa può fare l'oggetto. Definisce l'operazione eseguita sugli oggetti.

• Class- Una classe incapsula i dati e il suo comportamento. Oggetti con significato e scopo simili raggruppati insieme come classe.

• Methods- I metodi determinano il comportamento di una classe. Non sono altro che un'azione che un oggetto può eseguire.

• Message- Un messaggio è una chiamata di funzione o procedura da un oggetto a un altro. Sono informazioni inviate agli oggetti per attivare i metodi. Essenzialmente, un messaggio è una chiamata di funzione o procedura da un oggetto a un altro.

Caratteristiche del sistema orientato agli oggetti

Un sistema orientato agli oggetti viene fornito con diverse fantastiche funzionalità che vengono discusse di seguito.

Incapsulamento

L'incapsulamento è un processo di occultamento delle informazioni. È semplicemente la combinazione di processo e dati in un'unica entità. I dati di un oggetto sono nascosti al resto del sistema e disponibili solo tramite i servizi della classe. Consente il miglioramento o la modifica dei metodi utilizzati dagli oggetti senza influire su altre parti di un sistema.

Astrazione

È un processo di acquisizione o selezione del metodo e degli attributi necessari per specificare l'oggetto. Si concentra sulle caratteristiche essenziali di un oggetto rispetto alla prospettiva dell'utente.

Relazioni

Tutte le classi nel sistema sono correlate tra loro. Gli oggetti non esistono isolati, esistono in relazione con altri oggetti.

Esistono tre tipi di relazioni oggettuali:

• Aggregation - Indica la relazione tra un intero e le sue parti.

• Association - In questo, due classi sono correlate o connesse in qualche modo, ad esempio una classe lavora con un'altra per eseguire un compito o una classe agisce su un'altra classe.

• Generalization- La classe figlia si basa sulla classe genitore. Indica che due classi sono simili ma presentano alcune differenze.

Eredità

L'ereditarietà è una grande caratteristica che permette di creare sottoclassi da una classe esistente ereditando gli attributi e / o le operazioni delle classi esistenti.

Polimorfismo e legame dinamico

Il polimorfismo è la capacità di assumere molte forme diverse. Si applica sia agli oggetti che alle operazioni. Un oggetto polimorfico è quello che il tipo vero si nasconde all'interno di una classe super o genitore.

Nell'operazione polimorfica, l'operazione può essere eseguita in modo diverso da diverse classi di oggetti. Ci permette di manipolare oggetti di classi differenti conoscendo solo le loro proprietà comuni.

Approccio strutturato vs. Approccio orientato agli oggetti

La tabella seguente spiega come l'approccio orientato agli oggetti differisce dal tradizionale approccio strutturato:

Approccio strutturato	Approccio orientato agli oggetti
Funziona con approccio dall'alto verso il basso.	Funziona con l'approccio dal basso verso l'alto.
Il programma è suddiviso in numero di sottomoduli o funzioni.	Il programma è organizzato in base al numero di classi e oggetti.
Viene utilizzata la chiamata di funzione.	Viene utilizzato il passaggio dei messaggi.
Il riutilizzo del software non è possibile.	La riutilizzabilità è possibile.
La programmazione della progettazione strutturata di solito rimane fino alle fasi finali.	Programmazione della progettazione orientata agli oggetti eseguita in concomitanza con altre fasi.
Il design strutturato è più adatto per l'offshoring.	È adatto per lo sviluppo interno.
Mostra una chiara transizione dalla progettazione all'implementazione.	Transizione non così chiara dalla progettazione alla realizzazione.
È adatto per sistemi in tempo reale, sistemi embedded e progetti in cui gli oggetti non sono il livello di astrazione più utile.	È adatto per la maggior parte delle applicazioni aziendali, progetti di sviluppo di giochi, che dovrebbero essere personalizzati o estesi.
I diagrammi DFD e ER modellano i dati.	Diagramma di classe, diagramma di sequenza, diagramma del diagramma di stato e casi d'uso contribuiscono tutti.
In questo, i progetti possono essere gestiti facilmente grazie a fasi chiaramente identificabili.	In questo approccio, i progetti possono essere difficili da gestire a causa di transizioni incerte tra le fasi.

Linguaggio di modellazione unificato (UML)

UML è un linguaggio visivo che consente di modellare processi, software e sistemi per esprimere il design dell'architettura di sistema. È un linguaggio standard per la progettazione e la documentazione di un sistema in modo orientato agli oggetti che consente agli architetti tecnici di comunicare con lo sviluppatore.

È definito come un insieme di specifiche create e distribuite da Object Management Group. UML è estensibile e scalabile.

L'obiettivo di UML è fornire un vocabolario comune di termini orientati agli oggetti e tecniche di creazione di diagrammi sufficientemente ricco da modellare qualsiasi progetto di sviluppo di sistemi dall'analisi all'implementazione.

UML è composto da:

• Diagrams - È una rappresentazione pittorica del processo, del sistema o di una parte di esso.

• Notations - Consiste di elementi che lavorano insieme in un diagramma come connettori, simboli, note, ecc.

Esempio di notazione UML per la classe

Istanza diagramma-notazione UML

Operazioni eseguite sugli oggetti

Le seguenti operazioni vengono eseguite sugli oggetti:

• Constructor/Destructor- Creazione di nuove istanze di una classe ed eliminazione di istanze esistenti di una classe. Ad esempio, l'aggiunta di un nuovo dipendente.

• Query- Accedere allo stato senza modificare il valore, non ha effetti collaterali. Ad esempio, trovare l'indirizzo di un determinato dipendente.

• Update - Modifica il valore di uno o più attributi e influisce sullo stato dell'oggetto Ad esempio, la modifica dell'indirizzo di un dipendente.

Usi di UML

UML è abbastanza utile per i seguenti scopi:

• Modellazione del processo aziendale
• Descrivere l'architettura del sistema
• Mostra la struttura dell'applicazione
• Acquisizione del comportamento del sistema
• Modellazione della struttura dei dati
• Costruire le specifiche dettagliate del sistema
• Schizzo delle idee
• Generazione del codice del programma

Modelli statici

I modelli statici mostrano le caratteristiche strutturali di un sistema, descrivono la sua struttura di sistema e sottolineano le parti che compongono il sistema.

• Sono usati per definire nomi di classi, attributi, metodi, firme e pacchetti.

• I diagrammi UML che rappresentano il modello statico includono diagramma delle classi, diagramma degli oggetti e diagramma dei casi d'uso.

Modelli dinamici

I modelli dinamici mostrano le caratteristiche comportamentali di un sistema, ovvero come si comporta il sistema in risposta ad eventi esterni.

• I modelli dinamici identificano l'oggetto necessario e il modo in cui interagiscono tramite metodi e messaggi.

• Sono utilizzati per progettare la logica e il comportamento del sistema.

• I diagrammi UML rappresentano il modello dinamico includono diagramma di sequenza, diagramma di comunicazione, diagramma di stato, diagramma di attività.

Ciclo di vita dello sviluppo del sistema orientato agli oggetti

Consiste di tre macro processi:

• Analisi orientata agli oggetti (OOA)
• Progettazione orientata agli oggetti (OOD)
• Implementazione orientata agli oggetti (OOI)

Attività di sviluppo di sistemi orientati agli oggetti

Lo sviluppo di sistemi orientati agli oggetti comprende le seguenti fasi:

• Analisi orientata agli oggetti
• Design orientato agli oggetti
• Prototyping
• Implementation
• Test incrementali

Analisi orientata agli oggetti

Questa fase riguarda la determinazione dei requisiti di sistema e la comprensione dei requisiti di sistema build a use-case model. Un caso d'uso è uno scenario per descrivere l'interazione tra utente e sistema informatico. Questo modello rappresenta le esigenze dell'utente o la vista utente del sistema.

Comprende anche l'identificazione delle classi e delle loro relazioni con le altre classi nel dominio del problema, che costituiscono un'applicazione.

Design orientato agli oggetti

L'obiettivo di questa fase è progettare e perfezionare le classi, gli attributi, i metodi e le strutture identificati durante la fase di analisi, l'interfaccia utente e l'accesso ai dati. Questa fase identifica e definisce anche le classi o gli oggetti aggiuntivi che supportano l'implementazione del requisito.

Prototipazione

La prototipazione consente di comprendere appieno quanto sarà facile o difficile implementare alcune delle funzionalità del sistema.

Può anche dare agli utenti la possibilità di commentare l'usabilità e l'utilità del design. Può definire ulteriormente un caso d'uso e rendere la modellazione del caso d'uso molto più semplice.

Implementazione

Utilizza lo sviluppo basato su componenti (CBD) o lo sviluppo rapido di applicazioni (RAD).

Sviluppo basato su componenti (CBD)

CODD è un approccio industrializzato al processo di sviluppo del software che utilizza una vasta gamma di tecnologie come gli strumenti CASE. Lo sviluppo delle applicazioni passa dallo sviluppo personalizzato all'assemblaggio di componenti software pre-costruiti, pre-testati e riutilizzabili che funzionano tra loro. Uno sviluppatore CBD può assemblare componenti per costruire un sistema software completo.

Sviluppo rapido di applicazioni (RAD)

RAD è un insieme di strumenti e tecniche che possono essere utilizzati per creare un'applicazione più velocemente di quanto normalmente possibile con i metodi tradizionali. Non sostituisce SDLC ma lo integra, poiché si concentra maggiormente sulla descrizione del processo e può essere combinato perfettamente con l'approccio orientato agli oggetti.

Il suo compito è creare l'applicazione in modo rapido e implementare in modo incrementale la progettazione dei requisiti dell'utente attraverso strumenti come visual basic, power builder, ecc.

Test incrementali

Lo sviluppo del software e tutte le sue attività, inclusi i test, sono un processo iterativo. Pertanto, può essere un affare costoso se aspettiamo di testare un prodotto solo dopo il suo completo sviluppo. Qui entrano in gioco i test incrementali in cui il prodotto viene testato durante le varie fasi del suo sviluppo.