Gestione del progetto Ais. AIS “Gestione progetti. Concetti di base della progettazione AIS

Esistono molti metodi e opzioni per lo sviluppo dell'AIS, il cui utilizzo dipende da vari fattori, ad esempio le dimensioni delle imprese e (o) il loro IS, gli obiettivi della creazione di un IS, le risorse disponibili, ecc. Metodi e principi di progettazione un IS sono discussi nei capitoli precedenti.

Il ciclo di vita del progetto software è un insieme di fasi e fasi di sviluppo del software, dall'analisi del sistema e dallo sviluppo dei requisiti iniziali fino alla sua installazione (installazione) su un computer.

L'esperienza nello sviluppo e nell'implementazione di varie classi di AIS ha mostrato un'elevata efficienza (anche economica) della loro applicazione, soprattutto presso le grandi imprese. Si riflette nella buona organizzazione del lavoro e della produzione, aumentando l'accuratezza della pianificazione e attuazione dei compiti stabiliti, garantendo il ritmo dell'impresa, riducendo la quota di lavoro manuale, supporto informativo efficace (compreso quello operativo) per varie categorie di utenti, eccetera. Il periodo di ammortamento medio per tali sistemi di solito non supera i due anni.

Nello sviluppo dell'IS, nella maggior parte dei casi, viene data preferenza a soluzioni progettuali standard, adattate alle condizioni e capacità specifiche del Cliente. I singoli progetti vengono sviluppati in assenza di soluzioni standard o quando i parametri di base dell'organizzazione differiscono in modo significativo (di oltre il 10-15%) dalle soluzioni standard. Questo di solito si applica alle organizzazioni grandi e grandi.

Nessuno schema di sviluppo IC è assoluto. Sono possibili diverse opzioni, a seconda, ad esempio, delle condizioni iniziali in cui si realizza lo sviluppo: si sta sviluppando un sistema completamente nuovo; è già stata effettuata una ricognizione dell'impresa ed esiste un modello della sua attività; l'impresa dispone già di un SI che può essere utilizzato come prototipo iniziale o deve essere integrato con quello sviluppato.

Lo sviluppo di dettaglio del progetto AIS presuppone la disponibilità di un set completo di documentazione organizzativa, progettuale, tecnologica e operativa.

La progettazione di qualsiasi oggetto viene eseguita con:

• a) determinare il suo scopo funzionale (perché è necessario, cosa e come fa l'oggetto progettato),
• b) identificare le connessioni logiche (come l'oggetto progettato adempie al suo scopo funzionale, quali informazioni vengono elaborate e in quale sequenza),
• c) la scelta dei mezzi materiali per la realizzazione dell'oggetto progettato - l'aspetto funzionale, tecnologico e tecnico (supporti, strumenti informatici, ecc.),
• d) la collocazione spaziale (territoriale) di mezzi materiali di vendita nelle aree assegnate o utilizzabili,
• e) formazione dell'assetto organizzativo e gestionale dell'oggetto progettato (composizione di funzioni, poteri e responsabilità funzionali lavoratori)

Dopo aver scelto il metodo di progettazione AIS, è necessario pianificare un insieme di lavori per creare un sistema secondo le fasi tipiche del suo sviluppo. Il progetto viene revisionato e approvato dal Cliente. La progettazione AIS prevede l'implementazione di determinate fasi e fasi.

Per il successo dell'attuazione del progetto, è necessario stabilire traguardi reali con inizio e fine chiaramente contrassegnati. Lo sviluppo di un piano di lavoro dettagliato è associato a una descrizione dei processi e della loro sequenza eseguiti in ogni fase, degli specialisti, dei fondi e delle risorse necessari. Questo approccio aiuta in misura maggiore ad evitare omissioni ed errori. È necessario per i dipendenti che implementano l'implementazione di un progetto di automazione e ha anche un impatto positivo sulle persone che lo finanziano.

Un'efficace implementazione graduale del lavoro di progettazione è associata alla necessità di sviluppare un programma per la loro attuazione, comprese le risorse e i tempi (fasi) della loro attuazione (vedere grafici e figure precedenti). Le risorse includono il personale, l'hardware, il software, i finanziamenti e l'infrastruttura necessari. Allo stesso tempo, è meglio finanziarlo separatamente per ogni tipo di lavoro (acquisto di fondi e software, installazione, formazione, fasi di progettazione individuali, ecc.).

Per l'automazione tipi diversi attività (gestione, progettazione, ricerca, ecc.), comprese le loro combinazioni, utilizzano le disposizioni di GOST 34.601-90. Prevede le seguenti fasi e fasi di progettazione (tabella 1).

Tavolo 2

La norma afferma inoltre che:

• · Le fasi e le fasi svolte dalle organizzazioni che partecipano alla creazione dell'UA sono stabilite nei contratti e nei termini di riferimento basati su questo standard.
• · È consentito escludere la fase "Bozza di progetto" e le fasi separate del lavoro in tutte le fasi, per combinare "Progettazione tecnica" e "Documentazione di lavoro" in una fase "Progettazione tecnico-funzionante". A seconda delle specifiche dei sistemi nucleari creati e delle condizioni per la loro creazione, è consentito eseguire singole fasi di lavoro prima del completamento delle fasi precedenti, parallelamente all'esecuzione delle fasi di lavoro nel tempo, l'inclusione di nuove fasi di lavoro .

Il progetto tecnico (progetto preliminare) contiene schemi circuitali e documentazione di progettazione dell'oggetto di sviluppo e dei suoi componenti, un elenco di strumenti software già pronti selezionati e supporto tecnico(compresi tipi di computer, sistemi operativi, programmi applicativi, ecc.), algoritmi per la risoluzione di problemi per lo sviluppo di nuovi strumenti software).

Progettazione esecutiva - la fase di progettazione finale, in generale, che prevede il chiarimento e il dettaglio dei risultati delle fasi precedenti, la creazione e il test di un prototipo dell'oggetto di automazione, lo sviluppo e il test di prodotti software, documentazione tecnologica e operativa.

Nella pratica moderna di progettazione di sistemi informativi automatizzati (ad esempio, AIPS, ASNTI, ACS, ecc.), Può essere la fase iniziale della loro implementazione nel lavoro di un'organizzazione o servizio del Cliente del progetto, o il capo uno in una serie di altre organizzazioni automatizzate, servizi, ecc.

Lo sviluppo di dettaglio del progetto di sistema presuppone la disponibilità di un set completo di documentazione organizzativa, progettuale, tecnologica e operativa.

Lo standard statale GOST 19.102-77 stabilisce le seguenti fasi di sviluppo della documentazione del software:

• 1. Termini di riferimento;
• 2. Bozza di progetto;
• 3. Progettazione tecnica;
• 4. Bozza di lavoro;
• 5. Attuazione.

Si noti che per piccoli progetti il ​​numero di fasi può essere ridotto.

Nell'ambito dell'implementazione della prima fase "Formazione dei requisiti per l'AU", l'oggetto viene esaminato e viene motivata la necessità di creare un AIS, tenendo conto dei requisiti dell'utente per l'AIS progettato. Queste procedure della prima fase di progettazione fanno parte dello studio di pre-progettazione. Ciò può includere anche le procedure della seconda fase di progettazione - "Sviluppo del concetto di NPP".

Nel processo di ricerca pre-progettuale, è in corso uno studio di fattibilità per la fattibilità della creazione di un AIS; sviluppo dei requisiti generali per lo sviluppo dell'AIS.

Nel processo di ricerca pre-progettuale per eseguire il lavoro di progettazione necessario, vengono identificati:

• · risorse materiali,
• · risorse finanziarie,
• · risorse umane,
• · Risorse temporanee.

Attualmente, qualsiasi organizzazione ha a sua disposizione alcune risorse materiali, di regola, di origine eterogenea. Per garantire la sicurezza di queste risorse, è necessario tenere registri e nominare persone responsabili. La soluzione a questo problema può essere effettuata utilizzando varie applicazioni come 1C: Enterprise, AVARD e molte altre. Ma questi programmi sono molto costosi, sia in acquisto che in manutenzione. Richiedere un'istruzione e una formazione speciali del personale.

In fase di progettazione dovrebbe comprendere il processo di creazione di un prototipo dell'oggetto proposto o possibile.

La moderna tecnologia per la creazione di AIS è una combinazione di strumenti e metodi di progettazione efficaci che semplificano questo processo, riducono i costi, abbreviano i tempi del calendario di progettazione del sistema e migliorano la qualità dello sviluppo grazie a un'ampia selezione di soluzioni di progettazione avanzate comprovate.

al principale strumenti di progettazione può essere attribuito:

Soluzioni di progettazione tipiche (TPD) e pacchetti applicativi (PPP). TPR - un insieme di elementi algoritmici e software che garantiscono l'implementazione di attività su un computer con l'aiuto di mezzi tecnici appropriati;

Sistemi di progettazione assistita da computer (CAD), che comportano l'uso di computer in tutte le fasi della creazione dell'AIS.

Requisiti generali per gli strumenti di progettazione:

Copertura completa dell'intero processo di creazione dell'AIS;

Compatibilità, ad es. coerenza sia nel processo di creazione di un sistema sia nel processo del suo funzionamento;

Versatilità, ad es. la possibilità di utilizzare gli stessi strumenti per oggetti diversi;

Accessibilità nello sviluppo e semplicità (semplicità) nell'implementazione;

Possibilità di organizzare il processo di progettazione in modalità di interazione interattiva tra lo sviluppatore del sistema, il progettista e il computer;

Adattabilità ed economicità.

Tra metodi di progettazione assegnare:

Design originale;

Design tipico e sue tipologie: elementare, sottosistema, modulare, a gruppi;

Progettazione assistita da computer.

Il metodo di progettazione originale è tradizionale e focalizzato su un'impresa specifica. Caratteristica Questo metodo è lo sviluppo di metodi originali di ispezione degli oggetti e la creazione della documentazione necessaria sotto forma di un progetto individuale. Il vantaggio di questo metodo è il riflesso delle caratteristiche specifiche dell'oggetto di automazione nel progetto AIS. Gli svantaggi includono un'intensità di lavoro relativamente elevata e un lungo tempo di sviluppo, un basso indicatore di affidabilità funzionale e adattabilità alle mutevoli condizioni. I progetti creati con il metodo originale si prestano alla modernizzazione, tuttavia, in forma pura questo metodo è usato raramente. Oggi, durante la sua implementazione, vengono utilizzati vari strumenti di progettazione e solo alcune parti del progetto richiedono soluzioni di progettazione originali. Questo in qualche modo appiana i suoi difetti. Tuttavia, questo metodo rimane rilevante quando si automatizzano oggetti complessi e straordinari.

V condizioni moderne L'AIS di solito non è costruito da zero. Attualmente, nell'economia, a quasi tutti i livelli di gestione ea tutti gli oggetti economici, operano sistemi di elaborazione automatizzata delle informazioni. La crescente necessità di informazioni tempestive, di alta qualità e operative richiede la creazione di AIS su una nuova base tecnica e tecnologica.

La ricerca di modi razionali di progettare va nelle seguenti direzioni:

1. sviluppo di soluzioni progettuali standard implementate in pacchetti software applicati (PPP) per la risoluzione di problemi economici con il successivo collegamento del PPP alle specifiche condizioni di attuazione e funzionamento;

2. sviluppo di sistemi di progettazione automatizzata.

Il primo dei modi è la possibilità di utilizzare soluzioni di progettazione standard incluse nei pacchetti di programmi applicati.

Design tipico- un metodo industriale per la creazione di AIS utilizzando TPR e PPP. Questo metodo è caratterizzato dalla presenza di strumenti collaudati, standard organizzativi-economici, tecnici, informativi, matematici e di automazione del controllo software. L'applicazione di questo metodo consente di ridurre l'intensità del lavoro, ridurre i costi e ridurre i tempi di progettazione e migliorare la qualità del progetto. Il tipico processo di progettazione consiste nella selezione e nel vincolo dei sottosistemi di supporto secondo i requisiti di uno specifico AIS. La parte tipica dell'AIS è un complesso di informazioni, software e hardware. La tipicità del supporto informativo si realizza attraverso il rigoroso rispetto dell'unità della struttura della base informativa, della composizione degli array, delle forme dei documenti in ingresso e in uscita. La natura tipica del software si ottiene utilizzando il PPP e la natura tipica del supporto tecnico si ottiene utilizzando computer dello stesso tipo o di tipo combinato.

1. Una variante del metodo di progettazione tipico è il metodo design elementare, che si basa su TPR. Quando si sviluppa un progetto, viene utilizzata una soluzione già pronta con piccole modifiche e non ne viene sviluppata una nuova.

2. Quando si utilizza metodo modulare I TPR sono creati su base modulare, quando ogni soluzione progettuale è divisa in parti componenti separate - moduli che implementano una certa parte di TPR. Ciò consente di creare un progetto per un nuovo sistema automatizzato combinando singoli moduli standard.

3. Quando si utilizza metodo di progettazione del sottosistema per ogni sottosistema vengono creati progetti di soluzioni e pacchetti applicativi, a livello di sistema e funzionali. L'allocazione dei sottosistemi dipende dall'oggetto del processo economico e produttivo. Per ciascuno dei sottosistemi, vengono sviluppate la propria soluzione di progettazione automatizzata e il PPP, che può essere a livello di sistema o funzionale. I PPP a livello di sistema includono PPP di gestione dei dati, PPP di procedure di elaborazione dati standard, metodi di statistica matematica e programmazione discreta, ecc. I PPP funzionali includono pacchetti rivolti ad imprese industriali con produzione discreta o continua, in ambito non industriale, e gestione settoriale .

Un requisito importante per la RFP è la compatibilità, poiché quando si progetta AIS, è consigliabile utilizzare più pacchetti contemporaneamente. La progettazione di sistemi che utilizzano PPP si riduce infatti al vincolo di pacchetti selezionati secondo determinati parametri alle condizioni specifiche dell'oggetto di automazione. Qualità positive Questo approccio alla progettazione può essere definito: processo meno laborioso, riduzione dei tempi di progettazione rispetto al progetto originale, implementazione di metodi avanzati di elaborazione dei dati, semplificazione della documentazione del progetto (poiché viene utilizzata la documentazione del pacchetto), maggiore affidabilità dell'AIS progettato.

4. Inoltre, ci sono metodo di progettazione di gruppo... La sua essenza risiede nella selezione preliminare di un gruppo di oggetti dello stesso tipo in termini di caratteristiche. Tra questi, viene selezionato l'oggetto di base, per il quale viene sviluppato il progetto, e possono essere utilizzati vari metodi e metodi di progettazione. La cosa principale qui è garantire un'elevata adattabilità del progetto. La principale area di applicazione di questo metodo sono le strutture non industriali (ad esempio i magazzini).

Le seguenti attività si prestano più efficacemente all'automazione:

1. contabilità, anche gestionale e finanziaria. Il maggior numero di RFP è stato creato a fini contabili. Tra questi ci sono "1C: Contabilità", "Turbo-Contabile", "Info-Contabile", "Parus", "ABACUS", "Bambi +", ecc .;

2.servizio di informazione e informazione attività economica... Rappresentato dal seguente PPP: "GARANT" (fiscale, contabilità, audit, imprenditorialità, banche, regolamentazione valutaria, controllo doganale); "CONSULENTE +" (fiscale, contabilità, audit, imprenditorialità, banche, regolamentazione valutaria, controllo doganale).

3.economico e attività finanziarie... Rappresentato dalla seguente RFP:

a) "Analisi economica e previsione dell'impresa, organizzazione" (impresa "INEK"), che esplica le funzioni: analisi economica attività di un'impresa, impresa; redazione di business plan; studio di fattibilità per il rimborso del prestito; analisi e selezione delle opzioni per le attività; previsione del saldo, dei flussi di cassa e dei prodotti finiti.

b) Complesso di rete multiutente di automazione completa della società Galaktika (JSC Novy Atlant), che include pianificazione, gestione operativa, contabilità e controllo, analisi, inoltre, nell'ambito del DSS per garantire la soluzione della pianificazione aziendale problemi nell'utilizzo del PPP Project- Expert.

4. organizzazione del lavoro del capo;

5. automazione della circolazione documentale;

6. formazione.

Di recente, le imprese e le aziende preferiscono acquistare pacchetti e tecnologie già pronti e, se necessario, aggiungere il proprio software, poiché lo sviluppo del proprio AIS è associato a costi e rischi elevati. Di norma viene sviluppato e proposto un sistema di base, che viene adattato in base ai desideri dei singoli clienti. Allo stesso tempo, agli utenti vengono fornite consulenze che aiutano a ridurre al minimo i tempi di implementazione di sistemi e tecnologie, utilizzarli nel modo più efficace e migliorare le qualifiche del personale.

Sistemi di progettazione assistita da computer - il secondo, modo in rapido sviluppo di condurre il lavoro di progettazione.

Tra i metodi di progettazione assistita da computer, i metodi di progettazione del modello occupano un posto speciale. La creazione e l'uso di sistemi CAD fornisce un livello sufficientemente elevato di affidabilità funzionale, copertura completa di tutti i processi tecnologici, riduzione dell'intensità del lavoro di progettazione con la massima considerazione degli interessi dell'oggetto di automazione. Tuttavia, questo metodo è piuttosto costoso e richiede sviluppatori altamente qualificati. Il requisito chiave per CAD è la capacità di costruire e mantenere in uno stato adeguato un determinato modello di informazione economica globale dell'oggetto di automazione nel sistema di progettazione. Un modello è una visualizzazione esplicita dei componenti informativi di un oggetto di automazione e delle relazioni tra di essi. L'obiettivo principale della costruzione di un modello è creare un progetto AIS corrispondente a questo modello, tenendo conto e utilizzando attivamente tutte le caratteristiche dell'oggetto. Tale modello dovrebbe contenere in una forma formalizzata una descrizione degli insiemi di componenti dell'informazione e della relazione tra di essi, compresi i collegamenti informativi e l'interazione algoritmica. Utilizzando il metodo di progettazione del modello, approccio sistemico, che determina l'uso dei computer non solo in tutte le fasi della creazione del sistema, ma anche nel processo di analisi dei risultati della sua operazione industriale. Lo sviluppo e l'applicazione del CAD hanno predeterminato il passaggio alla creazione di progetti individuali, ma a un livello notevolmente superiore rispetto al metodo di progettazione originale.

Nell'ultimo decennio, è emersa una nuova direzione nel campo dell'automazione della progettazione di circuiti integrati e IT: Tecnologia di sviluppo software assistita da computer CASE(CASO - Software assistito da computer / Ingegneria dei sistemi). La crescente complessità dei sistemi informativi, i crescenti requisiti per essi hanno portato alla necessità di industrializzare le tecnologie per la loro creazione.

Tecnologia CASEè un insieme di metodi per l'analisi, la progettazione, lo sviluppo e la manutenzione dell'IS, supportati da un insieme di strumenti di automazione interconnessi. CASE è un toolkit per analisti di sistema, sviluppatori e programmatori che automatizza il processo di progettazione e sviluppo di circuiti integrati. I sistemi CASE sono utilizzati come un potente strumento per risolvere problemi di ricerca e progettazione, come l'analisi strutturale dell'area tematica, l'implementazione del progetto utilizzando l'ultima generazione di linguaggi di programmazione, il rilascio della documentazione del progetto, il test dell'implementazione del progetto, la pianificazione e il controllo degli sviluppi, la modellazione applicazioni aziendali per risolvere problemi operativi, pianificazione strategica e gestione delle risorse, ecc.

L'obiettivo principale di CASE è automatizzare il più possibile lo sviluppo e il funzionamento dei sistemi.

Quando si utilizzano le tecnologie CASE, la tecnologia del lavoro in tutte le fasi del ciclo di vita dei sistemi automatizzati cambia. Nei sistemi CASE, il design si basa su metodi di sviluppo visuali, mentre grafici, diagrammi, tabelle, diagrammi e spiegazioni testuali vengono utilizzati per descrivere il modello dell'IS progettato. Tali metodologie forniscono una descrizione rigorosa e descrittiva del sistema in progettazione, che inizia con una panoramica del sistema e poi approfondisce, diventando una struttura gerarchica con un numero crescente di livelli.

L'automazione della programmazione si basa sulla generazione automatica di codici di programma che contengono descrizioni dei dati, la logica principale della loro elaborazione, schemi di database, file di descrizione dell'interfaccia, ecc. I codici vengono ulteriormente perfezionati e perfezionati, ma in alcuni casi l'automazione raggiunge il 90%. Inoltre, la tecnologia CASE genera la documentazione di progetto necessaria pronta per l'uso.

Quando si utilizza la tecnologia CASE, viene fornito il supporto di un'unica base di progetto, ad es. tutte le informazioni sull'AIS sviluppato vengono automaticamente inserite in un unico database di progetto. Ciò mantiene la coerenza, la coerenza, la completezza e la ridondanza minima dei dati di progettazione.

La tecnologia CASE fornisce il lavoro di squadra dei team di sviluppo, perché diversi gruppi di specialisti sono dotati di strumenti adeguati, nonché la capacità di apportare modifiche al progetto in modo coerente e corretto da parte di vari specialisti in tempo reale.

Le tecnologie CASE sono utilizzate con successo per costruire quasi tutti i tipi di AIS. CASE viene anche utilizzato per creare modelli di sistema che aiutano le strutture commerciali a risolvere i problemi di pianificazione strategica, gestione finanziaria, determinazione delle politiche aziendali, formazione del personale, ecc.

CASE presenta i seguenti vantaggi principali:

Migliorare la qualità dell'IS (IT) creato attraverso il controllo automatico (in primis il controllo del progetto);

Consentire in breve tempo di creare un prototipo del futuro IS (IT), che consente di valutare rapidamente, nelle prime fasi, il risultato atteso;

Accelerare il processo di progettazione e sviluppo del sistema;

Libera lo sviluppatore dal lavoro di routine, permettendogli di concentrarsi interamente sulla parte creativa del design;

Supportano lo sviluppo e il mantenimento di un IS già funzionante.

Ormai è emersa una potente industria CASE, che riunisce centinaia di aziende e aziende di vari orientamenti. Tra questi spiccano:

Aziende-sviluppatrici di strumenti per l'analisi e la progettazione di IP e IT

Aziende-sviluppatrici di strumenti speciali con un focus su aree tematiche ristrette o in singole fasi del ciclo di vita della PI;

Società di formazione che organizzano seminari e corsi di formazione per specialisti;

Società di consulenza che forniscono assistenza pratica nell'utilizzo dei pacchetti CASE per lo sviluppo di IS specifici;

Aziende specializzate nella pubblicazione di periodici e bollettini sulle tecnologie CASE.

Nbsp; Modelli del ciclo di vita AIS

Modello del ciclo di vita AISè una struttura che descrive i processi, le azioni e le attività svolte e il corso di sviluppo, funzionamento e manutenzione durante l'intero ciclo di vita del sistema.

La scelta di un modello del ciclo di vita dipende dalle specificità, dalla scala, dalla complessità del progetto e dall'insieme delle condizioni in cui l'AIS viene creato e opera.

Il modello del ciclo di vita AIS include:

Risultati del lavoro in ogni fase;

Eventi chiave o punti di completamento e processo decisionale.

In conformità con i modelli ben noti del ciclo di vita del software, vengono determinati i modelli del ciclo di vita dell'AIS - cascata, iterativo, spirale.

I. Modello a cascata descrive l'approccio classico allo sviluppo di sistemi in qualsiasi area disciplinare; è stato ampiamente utilizzato negli anni '70 e '80.

Il modello a cascata prevede l'organizzazione sequenziale del lavoro e la caratteristica principale del modello è la divisione di tutto il lavoro in fasi. Il passaggio dalla fase precedente alla successiva avviene solo dopo il completamento completo di tutto il lavoro di quello precedente.

allocare cinque stadi di sviluppo stabili, praticamente indipendenti dall'area disciplinare (Fig. 1.1).

Sopra primo In questa fase viene effettuato uno studio dell'area problematica, vengono formulate le esigenze del cliente. Il risultato di questa fase è il capitolato d'oneri (incarico di sviluppo), concordato con tutte le parti interessate.

Durante secondo fase, in base ai requisiti dell'incarico tecnico, vengono sviluppate alcune soluzioni progettuali. Di conseguenza, viene visualizzato un insieme di documentazione del progetto.

Terzo fase - attuazione del progetto; in sostanza, lo sviluppo del software (codifica) in accordo con le decisioni progettuali della fase precedente. In questo caso le modalità di attuazione non sono di fondamentale importanza. Il risultato di questa fase è un prodotto software finito.

Sopra il quarto In questa fase viene verificata la conformità del software ricevuto ai requisiti indicati nel capitolato d'oneri. L'operazione di prova consente di identificare vari tipi di difetti nascosti che appaiono nelle condizioni reali dell'AIS.

L'ultima fase è la resa progetto finito, e la cosa principale qui è convincere il cliente che tutte le sue esigenze sono soddisfatte appieno.

Figura 1.1 Modello del ciclo di vita AIS a cascata

Le fasi di lavoro nell'ambito del modello a cascata sono spesso chiamate parti del ciclo di progettazione AIS, poiché le fasi consistono in molte procedure iterative per chiarire i requisiti di sistema e le opzioni di progettazione. Il ciclo di vita di AIS è molto più complicato e lungo: può includere un numero arbitrario di cicli di chiarimenti, modifiche e integrazioni a soluzioni progettuali già adottate e implementate. In questi cicli avviene lo sviluppo dell'AIS e la modernizzazione dei suoi singoli componenti.

I vantaggi del modello a cascata:

1) in ogni fase viene formato un set completo di documentazione di progetto che soddisfa i criteri di completezza e coerenza. Nelle fasi finali viene sviluppata la documentazione per l'utente, che copre tutti i tipi di supporto AIS previsti dagli standard (organizzativo, informativo, software, tecnico, ecc.);

2) l'attuazione sequenziale delle fasi di lavoro consente di pianificare i tempi di completamento e i relativi costi.

Il modello a cascata è stato originariamente sviluppato per risolvere vari tipi di problemi ingegneristici e fino ad ora non ha perso il suo significato per il campo applicato. Inoltre, l'approccio a cascata è ideale per lo sviluppo di AIS, poiché già all'inizio dello sviluppo è possibile formulare tutti i requisiti con sufficiente precisione per fornire agli sviluppatori la libertà di implementazione tecnica. Tali AIS, in particolare, comprendono sistemi di regolamento complessi e sistemi in tempo reale.

Svantaggi del modello a cascata:

Ritardo significativo nell'ottenimento dei risultati;

Errori e carenze in una qualsiasi delle fasi compaiono, di regola, nelle fasi successive del lavoro, il che porta alla necessità di tornare;

La complessità del lavoro parallelo sul progetto;

Eccessiva sovrasaturazione delle informazioni di ciascuna delle fasi;

Complessità della gestione del progetto;

Alto livello di rischio e inaffidabilità degli investimenti.

Ritardo nella ricezione dei risultati si manifesta nel fatto che un approccio coerente allo sviluppo dell'accordo dei risultati con gli stakeholder viene effettuato solo dopo il completamento della fase successiva di lavoro. Di conseguenza, potrebbe risultare che l'AIS sviluppato non soddisfa i requisiti e tali incongruenze possono sorgere in qualsiasi fase dello sviluppo; inoltre, gli errori possono essere introdotti inavvertitamente sia dai progettisti analitici che dai programmatori, poiché non devono essere esperti nelle aree tematiche per le quali viene sviluppato l'AIS.

Torna alle fasi precedenti. Questa mancanza è una delle manifestazioni della precedente: il lavoro sequenziale passo-passo su un progetto può portare al fatto che gli errori commessi nelle fasi precedenti vengono scoperti solo nelle fasi successive. Di conseguenza, il progetto viene riportato alla fase precedente, rielaborato e solo successivamente trasferito al lavoro successivo. Ciò può portare a un'interruzione del programma e complicare la relazione tra i gruppi di sviluppo che eseguono le singole fasi.

L'opzione peggiore è quando i difetti della fase precedente vengono scoperti non nella fase successiva, ma in un secondo momento. Ad esempio, nella fase dell'operazione di prova, possono apparire errori nella descrizione dell'area tematica. Ciò significa che una parte del progetto deve essere restituita alla fase iniziale del lavoro.

Complessità del lavoro parallelo connesso con la necessità di coordinare le diverse parti del progetto Quanto più forte è la relazione tra le singole parti del progetto, tanto più spesso e più accuratamente dovrebbe essere eseguita la sincronizzazione, tanto più i team di sviluppo dipendono l'uno dall'altro. Di conseguenza, i vantaggi del lavoro parallelo vengono semplicemente persi; la mancanza di parallelismo incide negativamente sull'organizzazione del lavoro dell'intero team.

Problema sovrasaturazione delle informazioni deriva da forti dipendenze tra i diversi gruppi di sviluppo. Il fatto è che quando si apportano modifiche a una delle parti del progetto, è necessario avvisare quegli sviluppatori che lo hanno utilizzato (potrebbero usarlo) nel loro lavoro. Con un gran numero di sottosistemi interconnessi, la sincronizzazione della documentazione interna diventa un'attività critica separata: gli sviluppatori devono costantemente familiarizzare con le modifiche e valutare come queste modifiche influenzeranno i risultati ottenuti.

Complessità della gestione del progetto principalmente per la rigorosa sequenza delle fasi di sviluppo e per la presenza di complesse relazioni tra le diverse parti del progetto. La sequenza di lavoro regolamentata porta al fatto che alcuni team di sviluppo devono attendere i risultati del lavoro di altri team, pertanto è necessario un intervento amministrativo per concordare tempi e composizione della documentazione presentata.

Se vengono rilevati errori nel lavoro, è necessario tornare alle fasi precedenti; il lavoro in corso di chi ha sbagliato è interrotto. La conseguenza di ciò è solitamente un ritardo nel completamento sia del progetto corretto che di quello nuovo.

È possibile semplificare l'interazione tra gli sviluppatori e ridurre il sovraccarico di informazioni della documentazione riducendo il numero di connessioni tra le singole parti del progetto, ma non tutti gli AIS possono essere suddivisi in sottosistemi debolmente accoppiati.

Alto livello di rischio. Quanto più complesso è il progetto, tanto più tempo impiega ogni fase di sviluppo e tanto più complesse sono le interconnessioni tra le singole parti del progetto, il cui numero aumenta anch'esso. Inoltre, i risultati dello sviluppo possono essere realmente visti e valutati solo nella fase di test, ovvero dopo il completamento delle fasi di analisi, progettazione e sviluppo, la cui implementazione richiede tempo e denaro significativi.

La valutazione tardiva crea seri problemi nell'identificare gli errori nell'analisi e nella progettazione: è necessario tornare alle fasi precedenti e ripetere il processo di sviluppo. Tuttavia, il ritorno alle fasi precedenti può essere associato non solo ad errori, ma anche a modifiche intervenute nell'area tematica o nei requisiti del cliente durante lo sviluppo. Allo stesso tempo, nessuno garantisce che l'area tematica non cambierà di nuovo quando sarà pronta la prossima versione del progetto. Di fatto, questo significa che c'è la probabilità di "loop" del processo di sviluppo: i costi del progetto aumenteranno costantemente e le scadenze per la consegna del prodotto finito vengono costantemente posticipate.

II. Modello iterativo consiste in una serie di brevi cicli (fasi) di progettazione, attuazione, studio, azione.

La creazione di AIS complessi comporta l'approvazione di soluzioni progettuali ottenute nell'attuazione delle singole attività. L'approccio di progettazione dal basso verso l'alto richiede tali iterazioni di rendimenti, quando le soluzioni di progettazione per le singole attività vengono combinate in soluzioni sistemiche comuni. Allo stesso tempo, è necessario rivedere i requisiti precedentemente formati.

Vantaggio il modello iterativo è che gli aggiustamenti tra le fasi forniscono uno sviluppo meno laborioso rispetto al modello a cascata.

svantaggi modello iterativo:

· La durata di ciascuna fase è estesa per l'intero periodo di lavoro;

· A causa di un gran numero di iterazioni, ci sono incongruenze nell'implementazione delle soluzioni progettuali e della documentazione;

· Complessità dell'architettura;

· Le difficoltà nell'utilizzo della documentazione di progettazione nelle fasi di implementazione e funzionamento richiedono la riprogettazione dell'intero sistema.

III. Modello a spirale, a differenza della cascata, ma simile alla precedente, prevede un processo iterativo di sviluppo dell'AIS. Allo stesso tempo, aumenta l'importanza delle fasi iniziali, come l'analisi e la progettazione, in cui viene verificata e giustificata la fattibilità delle soluzioni tecniche attraverso la creazione di prototipi.

Ogni iterazione rappresenta un ciclo di sviluppo completo che porta al rilascio di una versione interna o esterna di un prodotto (o di un sottoinsieme del prodotto finale), che migliora di iterazione in iterazione fino a diventare un sistema completo (Figura 1.2).

Riso. 1.2. Modello a spirale del ciclo di vita AIS

Pertanto, ogni giro della spirale corrisponde alla creazione di un frammento o versione di un prodotto software, gli obiettivi e le caratteristiche del progetto sono specificati su di esso, la sua qualità è determinata, il lavoro è pianificato per il prossimo giro della spirale. Ogni iterazione serve ad approfondire e concretizzare coerentemente i dettagli del progetto, a seguito del quale viene selezionata un'opzione ragionevole per l'implementazione finale.

L'utilizzo del modello a spirale consente di passare alla fase successiva del progetto senza attendere il completamento completo di quella corrente: il lavoro incompiuto può essere completato alla successiva iterazione. il compito principale ogni iterazione: crea un prodotto funzionante per la dimostrazione agli utenti il ​​prima possibile. Pertanto, il processo di apportare modifiche e integrazioni al progetto è notevolmente semplificato.

L'approccio a spirale allo sviluppo del software supera la maggior parte delle carenze del modello a cascata, inoltre fornisce una serie di funzionalità aggiuntive, rendendo il processo di sviluppo più flessibile.

Vantaggi approccio iterativo:

Lo sviluppo iterativo semplifica enormemente l'introduzione di modifiche al progetto quando cambiano le esigenze del cliente;

Quando si utilizza il modello a spirale, i singoli elementi AIS vengono gradualmente integrati in un unico insieme. Poiché l'integrazione inizia con meno elementi, ci sono molti meno problemi nella sua attuazione;

Ridurre il livello dei rischi (conseguenza del vantaggio precedente, poiché i rischi vengono rilevati proprio durante l'integrazione). Il livello di rischio è massimo all'inizio dello sviluppo del progetto, man mano che lo sviluppo progredisce, diminuisce;

Lo sviluppo iterativo offre una maggiore flessibilità nella gestione dei progetti consentendo di apportare modifiche tattiche al prodotto in fase di sviluppo. Quindi, puoi accorciare i tempi di sviluppo riducendo la funzionalità del sistema o utilizzarlo come componenti prodotti di società terze invece dei propri sviluppi (rilevante in un'economia di mercato, quando è necessario resistere alla promozione dei prodotti dei concorrenti);

Un approccio iterativo facilita il riutilizzo dei componenti perché è molto più facile identificare (identificare) le parti comuni del progetto quando sono già parzialmente sviluppate che cercare di isolarle all'inizio del progetto. L'analisi del progetto dopo diverse iterazioni iniziali rivela componenti riutilizzabili comuni che verranno migliorati nelle iterazioni successive;

Il modello a spirale consente un sistema più affidabile e stabile. Ciò è dovuto al fatto che man mano che il sistema si evolve, errori e punti deboli vengono scoperti e corretti ad ogni iterazione. Contestualmente vengono adeguati i parametri critici di prestazione, che nel caso di un modello a cascata sono disponibili solo prima dell'implementazione del sistema;

Un approccio iterativo migliora il processo
sviluppo: a seguito dell'analisi alla fine di ogni iterazione, viene effettuata una valutazione dei cambiamenti nell'organizzazione di sviluppo; migliora alla prossima iterazione.

Il problema principale del ciclo a spirale- la difficoltà di determinare il momento del passaggio alla fase successiva. Per risolverlo è necessario introdurre limiti temporali per ogni fase del ciclo di vita. In caso contrario, il processo di sviluppo può trasformarsi in un miglioramento senza fine di quanto già fatto.

Coinvolgere gli utenti nel processo di progettazione e copia dell'applicazione consente di ricevere commenti e integrazioni ai requisiti direttamente nel processo di progettazione dell'applicazione, riducendo i tempi di sviluppo. I rappresentanti dei clienti hanno l'opportunità di controllare il processo di creazione di un sistema e influenzarne il contenuto funzionale. Il risultato è la messa in servizio di un sistema che tiene conto della maggior parte delle esigenze del cliente.

Le moderne metodologie e le tecnologie di progettazione AIS che le implementano vengono fornite a in formato elettronico insieme a CASE-tools e includono librerie di processi, modelli, metodi, modelli e altri componenti destinati alla creazione di software della classe di sistemi a cui è focalizzata la metodologia. Le metodologie e le tecnologie elettroniche costituiscono il nucleo di un insieme di utensili sviluppo dell'AIS. Le caratteristiche delle moderne soluzioni metodologiche per la progettazione di AIS non possono essere implementate senza determinate tecnologie di progettazione che corrispondono alla scala e alle specifiche del progetto.

Tecnologia di progettazione AISè un insieme di metodi e strumenti per la progettazione dell'AIS, nonché metodi e strumenti per l'organizzazione della progettazione (gestione del processo di creazione e modernizzazione di un progetto AIS).

Secondo il design TP, l'AIS è un insieme di catene di azioni sequenziali-parallele, connesse e subordinate, ognuna delle quali può avere il proprio soggetto. Le azioni che vengono eseguite nella progettazione di AIS possono essere definite come operazioni tecnologiche indivisibili o come sottoprocessi di operazioni tecnologiche. Tutte le azioni possono essere corrette design, che modellano o modificano i risultati del progetto, e stimato, che sono sviluppati secondo i criteri stabiliti per la valutazione dei risultati del progetto.

Pertanto, la tecnologia di progettazione è impostata da una sequenza regolata di operazioni tecnologiche eseguite nel processo di creazione di un progetto basato su un metodo particolare.

L'oggetto della tecnologia di progettazione scelta dovrebbe essere il riflesso dei processi di progettazione correlati in tutte le fasi del ciclo di vita dell'AIS.

I requisiti principali per la tecnologia di progettazione scelta sono i seguenti:

· Il progetto realizzato con l'ausilio di questa tecnologia deve soddisfare le esigenze del cliente;

· La tecnologia dovrebbe riflettere il più possibile tutte le fasi del ciclo di vita del progetto;

· La tecnologia dovrebbe fornire costi minimi di manodopera e costi per la progettazione e il supporto del progetto;

· La tecnologia dovrebbe contribuire alla crescita della produttività del lavoro dei progettisti;

· La tecnologia dovrebbe garantire l'affidabilità della progettazione e del funzionamento del progetto;

· La tecnologia dovrebbe facilitare la facile manutenzione della documentazione del progetto.

La tecnologia di progettazione AIS implementa una metodologia di progettazione specifica. A sua volta, la metodologia di progettazione presuppone la presenza di alcuni concetti, principi di progettazione ed è implementata da un insieme di metodi e strumenti.

I metodi di progettazione AIS possono essere classificati in base al grado di utilizzo degli strumenti di automazione, alle soluzioni progettuali tipiche, all'adattabilità ai cambiamenti previsti.

In base al grado di automazione, si distinguono:

disegno manuale, in cui la progettazione dei componenti AIS viene eseguita senza l'uso di strumenti software speciali; la programmazione avviene in linguaggi algoritmici;

computer design, in cui la generazione o la configurazione (tuning) di soluzioni progettuali viene eseguita utilizzando appositi strumenti software.

In base al grado di utilizzo delle soluzioni progettuali tipiche, si distinguono:

originale (individuale) design, quando le soluzioni progettuali sono sviluppate "da zero" in conformità con i requisiti per AIS;

design tipico, assumendo la configurazione dell'AIS da soluzioni progettuali standard già pronte (moduli software).

Design originale AIS assume la massima considerazione delle caratteristiche di una struttura automatizzata.

Design tipico eseguita sulla base soluzioni pronte ed è una generalizzazione dell'esperienza acquisita in precedenza nella creazione di progetti correlati.

Dal grado di adattabilità delle soluzioni progettuali i seguenti metodi differiscono:

ricostruzione- l'adattamento delle soluzioni progettuali viene effettuato elaborando i componenti corrispondenti (riprogrammazione dei moduli software);

parametrizzazione- le soluzioni progettuali sono regolate secondo i parametri specificati e variabili;

ristrutturazione del modello- cambia il modello dell'area disciplinare, che porta alla riforma automatica delle soluzioni progettuali.

La combinazione di vari segni di classificazione dei metodi di progettazione determina la natura della tecnologia di progettazione AIS utilizzata. Esistono due classi principali di tecnologia di progettazione: canonico e industriale... La tecnologia del design industriale è suddivisa in due sottoclassi: automatizzato(uso delle tecnologie CASE) e tipico progettazione (orientata ai parametri o orientata al modello).

Tabella 1.1.Caratteristiche delle classi di tecnologia di progettazione

Design AIS canonico si concentra principalmente sull'uso del modello a cascata del ciclo di vita AIS.

A seconda della complessità dell'oggetto di automazione e dell'insieme di attività che devono essere risolte durante la creazione di un AIS specifico, le fasi e le fasi di lavoro possono avere un'intensità di lavoro diversa. È consentito combinare fasi successive ed escluderne alcune in qualsiasi fase del progetto. È inoltre consentito iniziare i lavori della fase successiva prima della fine della precedente.

Le fasi e le fasi della creazione dell'AIS, eseguite dalle organizzazioni partecipanti, sono prescritte nei contratti e nei termini di riferimento per l'esecuzione del lavoro.

Fase 1. Formazione dei requisiti per l'AIS:

· Rilievo della struttura e giustificazione della necessità di creare AIS;

· Formazione dei requisiti utente per AIS;

· Preparazione di una relazione sul lavoro svolto e un incarico tattico e tecnico per lo sviluppo.

Fase 2. Sviluppo del concetto AIS:

· Studio dell'oggetto automazione;

· Svolgere il lavoro di ricerca necessario;

· Sviluppo di opzioni per il concetto di AIS, soddisfacendo le esigenze degli utenti;

· Preparazione del report e approvazione del concept.

Fase 3. Compito tecnico:

Sviluppo e approvazione delle specifiche tecniche per la realizzazione dell'AIS.

Fase 4. Progetto preliminare:

· Sviluppo di soluzioni progettuali preliminari per l'impianto e le sue parti;

· Sviluppo della documentazione di contorno per l'AIS e le sue parti.

Fase 5. Progetto tecnico:

· Sviluppo di soluzioni progettuali del sistema e delle sue parti;

· Sviluppo della documentazione per AIS e sue parti;

· Sviluppo ed esecuzione della documentazione per la fornitura dei componenti;

· Sviluppo di incarichi di progettazione in parti correlate del progetto.

Fase 6. Documentazione di lavoro:

· Sviluppo della documentazione di lavoro per AIS e sue parti;

· Sviluppo e adattamento di programmi.

Fase 7. La messa in produzione:

· Preparazione dell'oggetto automazione; formazione del personale;

· Set completo dei prodotti forniti da AIS (software e hardware, complessi software e hardware, prodotti informativi);

· Lavori di costruzione e installazione; messa in opera di lavori;

· Esecuzione di prove preliminari;

· Esecuzione di operazioni di prova;

· Esecuzione di prove di accettazione.

Fase 8. Accompagnatore AIS:

· Esecuzione dei lavori in ottemperanza agli obblighi di garanzia;

· Servizio post-garanzia.

IndagineÈ lo studio e l'analisi della struttura organizzativa dell'impresa, delle sue attività e il sistema esistente elaborazione delle informazioni.

I materiali ottenuti a seguito dell'indagine vengono utilizzati per:

Giustificazione per lo sviluppo e l'attuazione graduale dei sistemi;

Stesura di specifiche tecniche per lo sviluppo di sistemi;

Sviluppo di progetti tecnici ed esecutivi di impianti.

Nella fase di indagine, è opportuno distinguere due componenti: la definizione della strategia di implementazione dell'AIS e un'analisi dettagliata delle attività dell'organizzazione.

Il compito principale della prima fase del sondaggio è valutare il volume reale del progetto, i suoi obiettivi e obiettivi in ​​base alle funzioni identificate e agli elementi informativi dell'oggetto automatizzato di alto livello. Queste attività possono essere implementate sia dal cliente AIS in modo indipendente, sia con il coinvolgimento di organizzazioni di consulenza. Questa fase prevede una stretta interazione con i principali potenziali utilizzatori del sistema e con gli esperti di business. Il compito principale dell'interazione è ottenere una comprensione completa e univoca delle esigenze del cliente. In genere, le informazioni di cui hai bisogno possono essere ottenute attraverso interviste, conversazioni o workshop con management, esperti e utenti.

Al termine della fase di indagine, diventa possibile determinare i probabili approcci tecnici alla creazione di un sistema e stimare i costi della sua implementazione (per l'hardware, per il software acquistato e per lo sviluppo di nuovo software).

Il risultato della fase di definizione della strategia è un documento (studio di fattibilità - studio di fattibilità - progetto), dove viene chiaramente formulato ciò che il cliente riceverà se accetta di finanziare il progetto, quando riceverà il prodotto finito (programma di lavoro) e come molto costerà (per progetti di grandi dimensioni - questo è un programma di finanziamento in diverse fasi del lavoro). È auspicabile riflettere nel documento non solo i costi, ma anche i benefici del progetto, ad esempio il tempo di ammortamento del progetto, previsto effetto economico(se può essere valutato).

Limiti, rischi, criticità che possono influenzare il successo del progetto;

L'insieme delle condizioni in base alle quali dovrebbe operare il sistema futuro: architettura del sistema, risorse hardware e software, condizioni operative, personale di servizio e utenti del sistema;

Termini di espletamento delle singole fasi, modalità di accettazione/consegna dei lavori, risorse coinvolte, misure a tutela delle informazioni;

Descrizione delle funzioni svolte dal sistema;

Opportunità per lo sviluppo e l'ammodernamento del sistema;

Interfacce e distribuzione delle funzioni tra una persona e un sistema;

requisiti per software e sistemi di gestione di database (DBMS).

Nella fase di analisi dettagliata delle attività dell'organizzazione, vengono studiate le attività che garantiscono l'attuazione delle funzioni di gestione, struttura organizzativa, personale e contenuto del lavoro sulla gestione dell'impresa, nonché la natura della subordinazione agli organi direttivi superiori. Qui è necessario delineare i materiali istruttivi, metodologici e direttivi, in base ai quali vengono determinate la composizione dei sottosistemi e l'elenco dei compiti, nonché la possibilità di utilizzare nuovi metodi per risolvere i problemi.

Gli analisti raccolgono e registrano le informazioni in due forme correlate:

Funzioni: informazioni su eventi e processi che si verificano nell'organizzazione automatizzata;

Entità - Informazioni sulle classi di oggetti rilevanti per l'organizzazione e su quali dati vengono raccolti.

Quando si studia ciascun compito di controllo funzionale, si determina quanto segue:

Nome dell'attività; termini e frequenza della sua decisione;

Il grado di formalizzabilità del problema;

Fonti di informazioni necessarie per risolvere il problema;

Indicatori e loro caratteristiche quantitative;

La procedura per correggere le informazioni;

Algoritmi operativi per il calcolo degli indicatori e possibili modalità di controllo;

Mezzi esistenti di raccolta, trasmissione ed elaborazione di informazioni;

Mezzi di comunicazione esistenti;

Accuratezza accettata della soluzione del problema;

La complessità della soluzione del problema;

Forme esistenti di presentazione dei dati iniziali e dei risultati della loro elaborazione sotto forma di documenti;

Consumatori delle informazioni risultanti sul compito.

Uno dei compiti più laboriosi, anche se ben formalizzati, di questa fase è la descrizione del flusso di lavoro dell'organizzazione. Quando si esamina il flusso di lavoro, viene redatto un diagramma del percorso di movimento dei documenti, che dovrebbe riflettere:

Numero di documenti;

Luogo di formazione degli indicatori documentali;

Il rapporto dei documenti durante la loro formazione;

Il percorso e la durata del movimento del documento;

Luogo di utilizzo e conservazione di questo documento;

Comunicazioni informative interne ed esterne;

Il volume del documento in segni.

Sulla base dei risultati del sondaggio, viene stabilito un elenco di attività di gestione da automatizzare e la sequenza del loro sviluppo.

Durante la fase di rilievo, le funzioni di sistema previste dovrebbero essere classificate in base alla loro importanza. Uno dei possibili formati per presentare tale classificazione è MuSCoW. Questa abbreviazione sta per: Must have - funzioni richieste; Dovrebbe avere - funzioni desiderate; Potrei avere - io possibili funzioni; Non avrà funzionalità mancanti.

Le funzioni della prima categoria forniscono critiche per I lavoro di successo capacità dei sistemi. L'attuazione delle funzioni della seconda e della terza categoria è limitata dal tempo e dal quadro finanziario: si sta sviluppando il necessario, nonché il massimo possibile, in ordine di priorità, il numero di funzioni della seconda e della terza categoria. L'ultima categoria di funzioni è particolarmente importante, poiché è necessario comprendere chiaramente i confini del progetto I e l'insieme di funzioni che saranno assenti nel sistema.

I modelli di attività organizzativa sono creati in due tipi 1:

Il modello "as is" - riflette i processi aziendali esistenti nell'organizzazione;

Il modello “to be” riflette i necessari cambiamenti nei processi aziendali tenendo conto dell'introduzione dell'AIS. J

Già in fase di analisi, è necessario coinvolgere il gruppo di test nel lavoro per risolvere i seguenti compiti:

Ottenere caratteristiche comparative di piattaforme hardware, sistemi operativi, DBMS, ecc.;

Sviluppo di un piano di lavoro per garantire l'affidabilità dell'AIS e il suo collaudo.

Coinvolgere i tester nelle prime fasi dello sviluppo è una buona idea per qualsiasi progetto. Più tardi vengono scoperti errori nelle soluzioni progettuali, più costoso è risolverli; lo scenario peggiore è il loro rilevamento durante la fase di implementazione. Pertanto, prima i team di test iniziano a identificare gli errori nell'AIS, minore è il costo del lavoro sul sistema. Il tempo per testare il sistema e correggere gli errori rilevati dovrebbe essere fornito non solo nella fase di sviluppo, ma anche nella fase di progettazione.

Speciali sistemi di tracciamento dei bug sono progettati per facilitare e aumentare l'efficacia dei test. Il loro utilizzo consente di avere un unico repository di errori, tenere traccia della loro ricorrenza, controllare la velocità e l'efficienza della correzione dei bug, vedere i componenti di sistema più instabili e anche mantenere la comunicazione tra il team di sviluppo e il team di test.

I risultati dell'indagine rappresentano una base oggettiva per la formazione delle specifiche tecniche dell'AIS.

Compito tecnicoÈ un documento che definisce gli obiettivi, i requisiti e i dati iniziali di base necessari per lo sviluppo di un sistema di controllo automatizzato.

Quando si sviluppa un incarico tecnico (TOR), è necessario risolvere i seguenti compiti:

· Stabilire lo scopo generale della creazione dell'AIS;

· Stabilire i requisiti generali per il sistema progettato;

· Sviluppare e convalidare i requisiti di supporto informativo, matematico, software, hardware e tecnologico;

· Determinare la composizione dei sottosistemi e dei compiti funzionali;

· Sviluppare e giustificare i requisiti per i sottosistemi;

· Determinare le fasi di realizzazione del sistema e le tempistiche della loro attuazione;

Effettuare un calcolo preliminare dei costi di creazione di un sistema e determinare il livello efficienza economica implementazione;

· Determinare la composizione degli esecutori.

I requisiti tipici per la composizione e il contenuto delle specifiche tecniche sono riportati nella tabella. 1.6.

Tablitsa 1.6. La composizione e il contenuto del compito tecnico (GOST 34.602-89)

Progetto esclusivo prevede lo sviluppo di soluzioni progettuali preliminari per il sistema e le sue parti. La progettazione preliminare non è una fase strettamente obbligatoria. Se le principali soluzioni progettuali sono definite in precedenza o sono abbastanza ovvie per uno specifico AIS e oggetto di automazione, questa fase può essere esclusa dalla sequenza generale dei lavori.

funzioni AIS;

Funzioni dei sottosistemi, loro obiettivi e l'effetto atteso dell'implementazione;

Composizione di insiemi di compiti e compiti individuali;

Concetto di base informativa e sua struttura allargata;

Funzioni del sistema di gestione del database;

Composizione di un sistema informatico e altri mezzi tecnici;

Funzioni e parametri dei principali software.

Sulla base dei risultati del lavoro svolto, viene redatta, concordata e approvata la documentazione nella misura necessaria per descrivere l'intero insieme delle decisioni progettuali adottate e sufficiente per ulteriori lavori sulla creazione del sistema.

In conformità con GOST 19.102-77, la fase di progettazione preliminare comprende due fasi: sviluppo di un progetto preliminare; approvazione della bozza di progetto.

La prima fase di sviluppo consiste in:

Sviluppo preliminare della struttura dei dati di input e output;

Affinamento dei metodi per la risoluzione del problema;

Sviluppo di una descrizione generale dell'algoritmo per la risoluzione del problema;

Sviluppo di uno studio di fattibilità;

Sviluppo di una nota esplicativa.

In questo caso, è consentito combinare ed escludere alcune opere.

Di seguito è riportato un insieme di documenti che dovrebbero e possono essere preparati alla fine del progetto di schizzo.

Documenti obbligatori:

1) termini di riferimento aggiornati per la progettazione e lo sviluppo
lavoro dell'AIS;

2) specifica dei requisiti di qualificazione per AIS;

3) un insieme di specifiche dei requisiti per i componenti software funzionali e le descrizioni dei dati;

4) specifica dei requisiti per le interfacce interne del componente e per le interfacce con l'ambiente esterno;

5) una descrizione del sistema di gestione del database, struttura e distribuzione del software e degli oggetti informativi nel database;

6) elaborare linee guida per la protezione delle informazioni e per garantire l'affidabilità del funzionamento dell'AIS;

7) una versione preliminare del manuale dell'amministratore AIS;

8) una versione preliminare del manuale utente AIS;

9) un piano rivisto per l'attuazione del progetto;

10) piano di gestione della garanzia della qualità AIS perfezionato;

11) nota esplicativa del progetto preliminare AIS;

12) un contratto rivisto (accordo) con il cliente per un dettaglio-
nuovo design dell'AIS.

Documenti redatti previo accordo con il cliente:

1) una descrizione preliminare del funzionamento dell'AIS;

2) un diagramma dei flussi di dati tra le componenti funzionali dell'AIS;

3) un raffinato diagramma dell'architettura AIS, dell'interazione tra software e componenti informativi, dell'organizzazione del processo informatico e dell'allocazione delle risorse;

4) una descrizione degli indicatori di qualità dei componenti e dei requisiti per gli stessi per fasi di sviluppo dell'AIS;

5) relazione su indicatori tecnici ed economici, tempistica di attuazione del progetto, allocazione delle risorse e budget;

6) una tabella di distribuzione degli specialisti per componenti e per fasi di lavoro;

7) certificati degli sviluppatori per il diritto di utilizzare strumenti tecnologici e di automazione per lo sviluppo di AIS;

8) una descrizione dei requisiti per la composizione e le forme dei documenti risultanti per fasi di lavoro;

9) un piano per il debug dei componenti software, dotandolo di metodi e strumenti di automazione dei test;

10) guida preliminare per la progettazione dettagliata
vaniya, programmazione e debug di componenti AIS;

11) progetto preliminare di vendita e realizzazione;

12) una descrizione della struttura preliminare della banca dati.

Progetto tecnico i sistemi sono documentazione tecnica contenente soluzioni progettuali a livello di sistema, algoritmi per la risoluzione dei problemi, nonché una valutazione dell'efficienza economica dell'AIS In questa fase, viene svolto un complesso di ricerca e lavoro sperimentale per selezionare le principali soluzioni progettuali e calcolare l'efficienza economica del sistema. Composizione e contenuto progetto tecnico sono riportati in tabella. 1.7

Tabella 1.7. Contenuto del progetto tecnico

Nella fase "Documentazione di lavoro", viene creato un prodotto software e viene sviluppata tutta la documentazione di accompagnamento. La documentazione dovrebbe contenere tutte le informazioni necessarie e sufficienti per garantire l'esecuzione del lavoro sulla messa in servizio dell'AIS e il suo funzionamento, nonché per mantenere il livello delle caratteristiche operative (qualità) del sistema. La documentazione sviluppata deve essere adeguatamente redatta, concordata e approvata.

Nella fase di "Messa in funzione" per l'AIS, vengono stabilite le seguenti principali tipologie di prove: prove preliminari, funzionamento di prova e prove di accettazione. Se necessario, è consentito condurre anche altri tipi di test del sistema e delle sue parti.

A seconda della relazione tra i componenti AIS e l'oggetto di automazione, i test possono essere autonomi e complessi. I componenti del sistema sono coinvolti in test autonomi. Vengono eseguiti non appena le parti del sistema sono pronte per la messa in servizio. Vengono eseguiti test complessi per gruppi di componenti interconnessi (sottosistemi) o per il sistema nel suo insieme.

Per pianificare lo svolgimento di tutti i tipi di test, è in fase di sviluppo il documento "Programma e metodologia di test". Lo sviluppatore del documento è stabilito nel contratto o TK. Test o casi di test possono essere inclusi nel documento come allegato.

Il debug è il processo di progettazione che richiede più tempo. Gli errori nascosti a volte compaiono dopo molti anni di funzionamento del sistema. È impossibile evitare completamente gli errori, a causa del numero astronomico di opzioni per il funzionamento del sistema. È quasi impossibile controllarli tutti per il corretto funzionamento nel prossimo futuro.

Il costo per identificare ed eliminare gli errori nelle fasi di progettazione successive aumenta in modo approssimativamente esponenziale (Figura 1.10).

I ricercatori contano 169 tipi di errori, riassunti in 19 grandi classi:

1) logico;

2) errori di manipolazione dei dati;

3) Errori di I/O;

4) errori di calcolo;

Riso. 1.10. Il costo relativo per rilevare e correggere un singolo errore

5) errori nelle interfacce utente;

6) errori nel sistema operativo e nei programmi ausiliari;

7) errori di impaginazione;

8) errori nelle interfacce di interprogrammazione;

9) errori nelle interfacce "Programma - software di sistema";

10) errori nella gestione di dispositivi esterni;

11) errori di interfacciamento con il database (DB);

12) errori di inizializzazione del database;

13) errori di modifica su richiesta dall'esterno;

14) errori relativi a variabili globali;

15) errori ripetitivi;

16) errori nella documentazione;

17) violazione dei requisiti tecnici;

18) errori non riconosciuti;

19) errori dell'operatore.

Non tutti i bug provengono dallo sviluppatore. Secondo vari ricercatori, dal 6 al 19% degli errori sono causati da errori nella documentazione.

La relazione tra sviluppo e test nelle varie fasi della progettazione AIS è mostrata in Fig. 1.11.

Questa catena è solo condizionatamente "allungata" in una linea. Ci sono sempre cicli ricorrenti al suo interno. Per identificare gli errori, gli sviluppatori creano test speciali e conducono una fase di debug. Se non vengono rilevati errori, ciò non significa che non ce ne siano, forse il test si è rivelato troppo debole.

Riso. 1.11. Correlazione tra sviluppo e test per fasi della progettazione AIS

La tecnica di debug tiene conto dei sintomi di possibili errori:

Elaborazione errata (risposta errata, risultato) - fino al 30%;

Trasferimento errato del controllo - 16%;

Incompatibilità dei programmi con i dati utilizzati - 15%;

Incompatibilità dei programmi per i dati trasmessi - fino al 9%.

Quando si sviluppano attività di debug, vengono risolte le seguenti attività:

Test di scrittura;

Selezione di punti, zone e percorsi di controllo;

Determinazione dell'elenco delle grandezze controllate e procedura per la fissazione dei loro valori;

Impostazione dell'ordine dei test;

Valutazione dell'affidabilità e della complessità del debug.

Il programma in fase di debug deve almeno una volta lavorare attraverso ogni ramo dell'algoritmo e allo stesso tempo assegnare una serie di valori alle variabili, catturando i confini dell'intervallo, diversi valori al suo interno, zero valori e punti singolari (se presenti). Per i sistemi specializzati, vengono sviluppati linguaggi di debug speciali. Possono contenere un numero relativamente piccolo di comandi (20-30) con parametri di ottimizzazione aggiuntivi per risolvere i seguenti compiti:

Controllo del prelievo;

Modellare il processo di esecuzione del programma in fase di debug;

Emissione dello stato dei componenti di memoria durante l'esecuzione del programma;

Verifica delle condizioni per il raggiungimento di determinati stati nel processo di esecuzione del programma;

Stabilire i valori di prova dei dati iniziali;

Implementazione di salti condizionali nei test in funzione dei risultati dell'esecuzione di altre macro o test vari;

Esecuzione di operazioni di servizio per preparare il programma per il test.

Il processo di debug non può essere classificato come completamente formalizzato, pertanto esistono raccomandazioni empiriche per il suo svolgimento, che sono riportate di seguito.

1. Utilizzare un approccio semantico e premeditato al debug, pianificare il processo di debug e progettare con cura i set di dati di test dalle opzioni più semplici possibili, eliminando le fonti di errore più probabili.

2. Raccogliere e analizzare le informazioni per semplificare il processo di test:

Caratteristiche e statistiche di errore;

Sulla specificità dei dati iniziali e sulla sequenza di modifica delle variabili nel programma e sulla loro reciproca influenza;

Sulla struttura dell'algoritmo e sulle caratteristiche della sua implementazione software.

3. Individuare un solo errore alla volta.

Utilizzare i mezzi per registrare e visualizzare informazioni sugli errori, incluso nel programma un codice di debug speciale per stampare valori campionati di variabili, messaggi sulla fine delle singole sezioni del programma, traccia, condizioni logiche, ecc.

5. Studiare attentamente l'output risultante e confrontarlo con i risultati attesi e precalcolati.

6. Prestare attenzione ai dati, analizzare attentamente il funzionamento del programma quando si utilizzano i valori limite e quando si immettono in modo errato; controllare i tipi di dati, gli intervalli, le dimensioni dei campi e la precisione.

7. Utilizzare il flusso di dati e l'analisi del flusso di controllo per convalidare e stabilire ambiti di dati per diversi percorsi di esecuzione del programma.

8. Utilizzare una varietà di strumenti di debug allo stesso tempo, senza soffermarsi su una possibilità. Utilizza strumenti automatizzati e debug e test manuali allo stesso tempo, verificando le prestazioni del codice rispetto agli errori più probabili.

9. Documentare eventuali errori trovati e corretti, le loro differenze, posizione e tipo. Queste informazioni saranno utili per prevenire errori futuri.

10. Misurare la complessità dei programmi. Nei programmi con elevata complessità, c'è un'alta probabilità di errori di specifica e progettazione e con bassa complessità, errori di codifica e di trascrizione.

11. Per aumentare l'esperienza e la pratica nel debug, inserire artificialmente errori nei programmi. Dopo un certo periodo di debug, il programmatore dovrebbe segnalare eventuali errori rimanenti che non ha trovato. Tale "seeding" è ampiamente utilizzato per stimare il numero di errori non rilevati (se sia gli errori artificiali che quelli reali vengono rilevati e corretti uniformemente, allora la percentuale degli errori introdotti introdotti e degli errori reali può essere utilizzata per prevedere quanti di essi rimangono).

Vengono effettuati test preliminari per determinare l'operatività del sistema e per risolvere il problema della possibilità della sua accettazione in funzionamento di prova. I test preliminari devono essere eseguiti dopo che lo sviluppatore ha eseguito il debug e testato il software e l'hardware del sistema forniti e ha presentato i documenti pertinenti sulla loro disponibilità per i test, nonché dopo che il personale AIS ha acquisito familiarità con la documentazione operativa.

Il funzionamento di prova del sistema viene effettuato al fine di determinare i valori effettivi delle caratteristiche quantitative e qualitative del sistema e la disponibilità del personale a lavorare nelle condizioni del suo funzionamento, nonché per determinare l'effettiva efficienza e regolare , se necessario, la documentazione.

Vengono effettuati test di accettazione per determinare la conformità del sistema alle specifiche tecniche, valutare la qualità del funzionamento di prova e risolvere il problema della possibilità di accettare il sistema in funzionamento permanente.

Inviare il tuo buon lavoro nella knowledge base è semplice. Usa il modulo sottostante

Studenti, dottorandi, giovani scienziati che utilizzano la base di conoscenza nei loro studi e nel loro lavoro ti saranno molto grati.

postato su http://www.allbest.ru/

Ministero dell'Istruzione e della Scienza Federazione Russa

Bilancio dello Stato federale Istituto d'Istruzione formazione professionale superiore

Università statale di tecnologia e design di San Pietroburgo

Lavoro del corso

Per disciplina: "Architettura dei sistemi informativi"

Sul tema: "Progettazione di sistemi informativi automatizzati"

INTRODUZIONE

Attualmente, la tecnologia informatica sta diventando sempre più diffusa sia nella produzione che nel flusso di lavoro delle imprese e l'elenco dei compiti da essa coperti sta diventando sempre più ampio. Il volume e la complessità delle informazioni in elaborazione è in costante crescita e sono richiesti nuovi tipi di presentazione.

Di seguito sono riportati solo alcuni dei vantaggi dell'utilizzo dell'informatica per un'organizzazione:

* Possibilità di controllo operativo sull'accuratezza delle informazioni;

* Ridurre il numero di possibili errori durante la generazione di dati derivati;

* Possibilità di accedere rapidamente a qualsiasi dato;

* Possibilità di generare rapidamente report;

* Risparmio sui costi del lavoro e sul tempo speso per l'elaborazione delle informazioni.

Tutti questi vantaggi sono attualmente apprezzati da molte organizzazioni, quindi oggi esiste un processo di rapido sviluppo di sistemi informativi automatizzati e la loro implementazione nel lavoro di varie istituzioni. A questo proposito, l'argomento che ho scelto è molto attuale in questo momento.

La caratteristica principale dell'industria dei sistemi di automazione per varie imprese e istituzioni, caratterizzata da un'ampia gamma di dati di input con vari percorsi per l'elaborazione di questi dati, è la concentrazione della complessità nelle fasi iniziali dell'analisi dei requisiti e della progettazione delle specifiche di sistema con relativamente bassa complessità e laboriosità delle fasi successive. In effetti, è qui che avviene la comprensione di ciò che farà il sistema futuro e di come funzionerà per soddisfare le richieste che gli vengono fatte. Vale a dire, la vaghezza e l'incompletezza dei requisiti di sistema, le questioni irrisolte e gli errori commessi nelle fasi di analisi e progettazione danno origine a problemi difficili, spesso irrisolvibili nelle fasi successive e, infine, portano al fallimento dell'intera opera nel suo insieme. Una semplice replica anche di un ottimo sistema di gestione aziendale non soddisferà mai completamente il cliente, poiché non può tener conto delle sue specificità. Inoltre, in questo caso, sorge il problema di scegliere esattamente il sistema più adatto a una determinata impresa. E questo problema è ulteriormente complicato dal fatto che le parole chiave che caratterizzano i vari sistemi informativi sono praticamente le stesse:

* Ambiente informativo unificato dell'impresa;

* Modalità in tempo reale;

* Indipendenza dalla legislazione;

* Integrazione con altre applicazioni (compresi i sistemi già operativi in ​​azienda);

* Implementazione graduale, ecc.

In effetti, il problema dell'automazione complessa è diventato rilevante per ogni impresa. E per eseguire automazioni complesse, è necessaria una conoscenza strutturata in quest'area.

Lo scopo di questo lavoro: familiarizzare con il concetto di sistemi informativi automatizzati, considerare il processo di progettazione.

Per raggiungere l'obiettivo, è necessario risolvere i seguenti compiti:

§ Formulare definizioni di concetti e termini di base;

§ Considerare gli scopi e gli obiettivi del progetto;

§ Conoscere le principali fasi della progettazione;

§ evidenziare le fasi di sviluppo dei sistemi informativi automatizzati;

§ Considerare la composizione e la struttura dell'incarico tecnico e del progetto tecnico.

1. DEFINIZIONE DEI CONCETTI SISTEMA INFORMATIVO AUTOMATICO (AIS), SISTEMA INFORMATIVO (IS), PROGETTO E DESIGN

Quando si strutturano i processi nel campo dell'attività umana, vengono utilizzati diversi metodi di isolamento dei componenti (sottoprocessi) e si ottengono vari risultati, come ricerca e sviluppo, analisi e sintesi, ecc.

La progettazione è abbastanza accettabile per essere considerata come un concetto generalizzante per molti compiti intellettuali risolti nel processo del pensiero e distinti in modi diversi.

La radice della parola design sottolinea la connessione tra il processo che ha un tale nome e i principali risultati di questo processo, come segue:

a) proiezione - cosa si ottiene analizzando fenomeni complessi al fine di ottenere rappresentazioni semplificate, e

b) progetto - cosa si ottiene sintetizzando rappresentazioni complesse da un insieme di immagini più semplici.

Le due ragioni sopra citate sono servite da giustificazione per l'attuale scelta della parola design come termine che denota l'essenza dell'attività principale che si svolge in informatica.

Nella progettazione dei sistemi informativi, i sistemi informativi sono gli oggetti del design, e questo è abbastanza naturale per l'informatica (dato che gli IS sono considerati i suoi oggetti principali).

Come sapete, i sistemi informativi sono in grado di visualizzare i fenomeni più diversi dell'universo e, quindi, tutti i fenomeni si rivelano anche potenziali oggetti di design.

I sistemi informativi in ​​molti casi risultano essere oggetto di progettazione, ovvero quegli esecutori che realizzano il processo di progettazione stesso. Studiando il processo di progettazione, siamo quindi in gran parte impegnati nello studio dei sistemi informativi.

Un sistema è inteso come qualsiasi oggetto che viene considerato contemporaneamente sia come un insieme unico sia come un insieme di elementi eterogenei combinati nell'interesse del raggiungimento degli obiettivi prefissati. I sistemi differiscono significativamente l'uno dall'altro sia nella composizione che in termini di obiettivi principali.

In informatica il concetto di sistema è molto diffuso e ha molti significati semantici. Il più delle volte viene utilizzato in relazione a un insieme di hardware e software. L'aggiunta al concetto della parola sistema informativo riflette lo scopo della sua creazione e funzionamento. I sistemi informativi forniscono la raccolta, l'archiviazione, l'elaborazione, la ricerca e la consegna delle informazioni necessarie nel processo di decisione sui problemi di qualsiasi campo. Aiutano ad analizzare i problemi e creare nuovi prodotti.

Sistema informativo (IS) - un insieme interconnesso di strumenti, metodi e personale utilizzato per archiviare, elaborare ed emettere informazioni al fine di raggiungere l'obiettivo.

Le moderne tecnologie dell'informazione forniscono un'ampia gamma di metodi di implementazione IP, la cui scelta si basa sui requisiti degli utenti previsti, che, di norma, cambiano durante il processo di sviluppo.

L'aggiunta del termine "automatizzato" al concetto di "sistema" riflette le modalità di creazione e funzionamento di tale sistema.

Sistema automatizzato(secondo GOST) è un sistema costituito da un insieme interconnesso di unità organizzative e da un insieme di strumenti di automazione delle attività che implementa funzioni automatizzate per alcuni tipi attività.

Un sistema informativo automatizzato (AIS) è un complesso di strumenti e personale software, tecnici, informativi, linguistici, organizzativi e tecnologici, progettati per risolvere i problemi dei servizi di riferimento e di informazione e (o) supporto informativo per gli utenti.

Un sistema informativo automatizzato è una raccolta di informazioni, metodi e modelli economici e matematici, strumenti tecnici, software, tecnologici e specialistici progettati per elaborare le informazioni e prendere decisioni gestionali.

Lo scopo principale dei sistemi informativi automatizzati non è solo quello di raccogliere e salvare risorse informative elettroniche, ma anche di fornire agli utenti l'accesso ad esse. Una delle caratteristiche più importanti di AIS è l'organizzazione del recupero dei dati nei loro array di informazioni (database).

Con il progetto AIS si intende la progettazione e la documentazione tecnologica, che fornisce una descrizione delle soluzioni progettuali per la creazione e il funzionamento dell'IS in uno specifico ambiente software e hardware.

Si possono distinguere le seguenti principali caratteristiche distintive del progetto come oggetto di gestione:

· Obiettivo finale limitato;

· Durata limitata;

· Budget limitato;

· Risorse limitate richieste;

· Novità per l'impresa per la quale si sta realizzando il progetto;

· Complessità;

· Supporto legale e organizzativo.

Considerando la pianificazione e la gestione del progetto, è necessario capire chiaramente che stiamo parlando della gestione di un determinato oggetto dinamico. Pertanto, il sistema di gestione del progetto deve essere sufficientemente flessibile da consentire modifiche senza cambiamenti globali in programma di lavoro... L'esecuzione dei lavori è assicurata dalla disponibilità delle risorse necessarie: materiali; attrezzatura; risorse umane. Dal punto di vista della teoria dei sistemi di controllo, il progetto come oggetto di controllo deve essere osservabile e controllabile, ovvero si distinguono alcune caratteristiche per cui è possibile monitorare costantemente l'andamento del progetto. Inoltre, sono necessari meccanismi per influenzare l'avanzamento del progetto in modo tempestivo.

Il design di AIS è inteso come il processo di conversione delle informazioni di input su un oggetto, metodi ed esperienza nella progettazione di oggetti con uno scopo simile in conformità con GOST in un progetto IS.

Da questo punto di vista, la progettazione dell'AIS si riduce alla formalizzazione sequenziale delle soluzioni progettuali nelle varie fasi del ciclo di vita dell'AIS: pianificazione e analisi dei requisiti, progettazione tecnica e di dettaglio, implementazione e funzionamento dell'AIS.

La scala dei sistemi in fase di sviluppo determina la composizione e il numero dei partecipanti al processo di progettazione. Con un grande volume e scadenze ravvicinate per l'implementazione del lavoro di progettazione, diversi team di progettazione (organizzazioni di sviluppo) possono prendere parte allo sviluppo del sistema. In questo caso, viene assegnata l'organizzazione madre, che coordina le attività di tutte le organizzazioni co-esecutrici.

La tecnologia di progettazione AIS è un insieme di metodologie e strumenti di progettazione per AIS, nonché metodi e mezzi della sua organizzazione (gestione del processo di creazione e modernizzazione di un progetto AIS).

La tecnologia del design si basa su un processo tecnologico che determina le azioni, la loro sequenza, la composizione richiesta di attori, mezzi e risorse.

Il processo tecnologico di progettazione dell'AIS nel suo insieme è suddiviso in un insieme di catene di azioni sequenziali-parallele, connesse e subordinate, ognuna delle quali può avere un proprio soggetto. Pertanto, la tecnologia di progettazione è impostata da una sequenza regolata di operazioni tecnologiche eseguite sulla base di un metodo o di un altro, a seguito della quale diventa chiaro non solo cosa dovrebbe essere fatto per creare un progetto, ma anche come, da chi, e in quale sequenza.

L'oggetto di qualsiasi tecnologia di progettazione selezionata dovrebbe essere il riflesso di processi di progettazione correlati in tutte le fasi del ciclo di vita dell'AIS. I requisiti principali per la tecnologia di progettazione scelta includono quanto segue:

· Il progetto realizzato deve soddisfare le esigenze del cliente;

· Massima riflessione di tutte le fasi del ciclo di vita del progetto;

· Garantire i costi minimi di manodopera e di costo per la progettazione e la manutenzione del progetto;

· La tecnologia dovrebbe essere la base per la comunicazione tra design e supporto al progetto;

· Aumento della produttività del progettista;

· Affidabilità del disegno e del funzionamento del progetto;

· Semplice manutenzione della documentazione di progetto.

La tecnologia progettuale AIS si basa sulla metodologia che ne definisce l'essenza, i principali tratti tecnologici distintivi.

Una metodologia di progettazione presuppone la presenza di alcuni concetti, principi di progettazione, implementati da un insieme di metodi, che, a loro volta, devono essere supportati da qualche mezzo.

L'organizzazione della progettazione prevede la definizione di modalità di interazione tra i progettisti e con il cliente nel processo di realizzazione di un progetto AIS, che può essere supportato anche da un insieme di strumenti specifici.

sistema informatico di progettazione assistita da computer

2. FINALITÀ E OBIETTIVI PROGETTUALI

La progettazione dei sistemi informativi inizia sempre con la definizione dell'obiettivo del progetto. Lo scopo della progettazione è la selezione dei tecnici e la formazione di informazioni, supporto matematico, software e organizzativo e legale.

La selezione del supporto tecnico dovrebbe essere tale da garantire la raccolta, la registrazione, il trasferimento, l'archiviazione, la compilazione e l'elaborazione tempestivi delle informazioni.

Il supporto informativo dovrebbe prevedere la creazione e il funzionamento di un unico fondo di informazioni del sistema, rappresentato da una varietà di array di informazioni, un insieme di dati o un database.

La formazione del supporto matematico dei sistemi include un insieme completo di metodi e algoritmi per la risoluzione di problemi funzionali. Nello sviluppo di sistemi software, viene prestata particolare attenzione alla creazione di una serie di programmi e istruzioni per l'utente e alla selezione di prodotti software efficaci.

Il compito principale di qualsiasi progetto di successo è garantire che al momento del lancio del sistema e durante il suo funzionamento, sia possibile garantire:

· La funzionalità richiesta del sistema e il grado di adattamento alle mutevoli condizioni del suo funzionamento;

· Il throughput richiesto del sistema;

· Il tempo di risposta richiesto del sistema alla richiesta;

· Funzionamento senza problemi del sistema nella modalità richiesta, in altre parole - la prontezza e disponibilità del sistema per elaborare le richieste degli utenti;

· Facilità di funzionamento e supporto del sistema;

· Sicurezza necessaria.

Le prestazioni sono il principale fattore determinante dell'efficienza del sistema. Un buon design è la base di un sistema ad alte prestazioni.

La progettazione di sistemi informativi automatizzati copre tre aree principali:

· Progettazione di oggetti dati che verranno implementati nel database;

· Progettazione di programmi, schermate, report che assicurino l'esecuzione di query sui dati;

· Tenendo conto di un ambiente o di una tecnologia specifici, ovvero: topologia di rete, configurazione hardware, architettura utilizzata (file-server o client-server), elaborazione parallela, elaborazione distribuita dei dati, ecc.

In condizioni reali, la progettazione è la ricerca di un metodo che soddisfi i requisiti di funzionalità del sistema mediante le tecnologie disponibili, tenendo conto dei vincoli dati.

A qualsiasi progetto sono imposti una serie di requisiti assoluti, ad esempio il tempo massimo di sviluppo del progetto, il massimo investimento finanziario nel progetto, ecc. Una delle difficoltà del design è che non è un compito così strutturato come analizzare i requisiti di un progetto o implementare una particolare soluzione di design.

3. FASI DI PROGETTAZIONE

Il processo di creazione dell'AIS è suddiviso in una serie di fasi (fasi), limitate da un certo lasso di tempo e che si concludono con il rilascio di un prodotto specifico.

Ogni progetto, indipendentemente dalla complessità e dal volume di lavoro richiesto per la sua attuazione, attraversa determinati stati nel suo sviluppo. Dallo stato in cui "il progetto non esiste ancora" allo stato in cui "il progetto non c'è più". L'insieme delle fasi di sviluppo dall'emergere di un'idea al completamento completo del progetto è solitamente suddiviso in fasi.

Lo scopo delle fasi iniziali della creazione dell'AIS, svolte nella fase di analisi delle attività dell'organizzazione, è formulare requisiti per l'AIS che riflettano correttamente e accuratamente gli obiettivi e gli obiettivi dell'organizzazione del cliente. Per specificare il processo di creazione di un AIS che soddisfi le esigenze dell'organizzazione, è necessario scoprire e articolare chiaramente quali sono queste esigenze. Per fare ciò, è necessario determinare i requisiti dei clienti per AIS e mapparli nel linguaggio dei modelli nei requisiti per lo sviluppo del progetto AIS in modo da garantire la conformità con gli obiettivi e gli obiettivi dell'organizzazione.

Si possono distinguere le seguenti fasi di sviluppo dei sistemi informativi automatizzati:

3.1 Formazione del concetto. Fase concettuale

Ciò comprende:

· Formazione dell'idea;

· Formazione di un team di progetto chiave;

· Studio delle motivazioni e delle esigenze del cliente e degli altri partecipanti;

· Raccolta dei dati iniziali e analisi dello stato esistente;

· Determinazione dei requisiti e delle restrizioni di base, delle risorse materiali, finanziarie e lavorative necessarie;

· Valutazione comparativa delle alternative;

· Presentazione delle proposte, loro esame e approvazione.

Il compito di formare i requisiti per l'AIS è uno dei più importanti, difficili da formalizzare e più costosi e difficili da correggere in caso di errore. Strumenti moderni e prodotti software consentono di creare rapidamente AIS in base ai requisiti già pronti. Ma spesso questi sistemi non soddisfano i clienti, richiedono numerose modifiche, il che porta a un forte aumento del costo del costo effettivo dell'AIS. Il motivo principale di questa situazione è la definizione errata, imprecisa o incompleta dei requisiti per l'AIS in fase di analisi.

3.2 Preparazione di una proposta tecnica

§ sviluppo dei contenuti principali della struttura di base del progetto;

§ sviluppo e approvazione delle specifiche tecniche;

§ pianificazione, scomposizione del modello strutturale di base del progetto;

§ stesura preventivi e budget del progetto;

§ sviluppo piani di calendario e orari di lavoro ampliati;

§ stipulare un contratto con il cliente;

§ mettere in opera i mezzi di comunicazione dei partecipanti al progetto e mezzi di controllo sullo stato di avanzamento dei lavori.

3.3 Progettazione

Nella fase di progettazione, vengono determinati i sottosistemi, le loro interrelazioni e vengono selezionate le modalità più efficaci di utilizzo del progetto e delle risorse. Lavori tipici di questa fase:

§ esecuzione di lavori di progettazione di base;

§ sviluppo di specifiche tecniche private;

§ implementazione del progetto concettuale;

§ redazione di specifiche tecniche e istruzioni;

§ presentazione dello sviluppo progettuale, esame e approvazione.

Nella fase di progettazione, vengono prima formati i modelli di dati. I progettisti ricevono i risultati dell'analisi come input. La creazione di modelli di dati logici e fisici è una parte essenziale della progettazione di database. Il modello di informazione ottenuto durante l'analisi viene prima trasformato in un modello di dati logico e poi in un modello di dati fisico.

3.4 Sviluppo

Nella fase di sviluppo, vengono eseguiti il ​​coordinamento e il controllo operativo del lavoro del progetto, i sottosistemi vengono prodotti, combinati e testati.

Dopo che il test autonomo è stato superato con successo, il modulo viene incluso nella parte sviluppata del sistema e un gruppo di moduli generati viene sottoposto a test di comunicazione, che dovrebbero tenere traccia della loro reciproca influenza.

Inoltre, un gruppo di moduli viene testato per l'affidabilità del funzionamento, ovvero superano, in primo luogo, i test per simulare i guasti del sistema e, in secondo luogo, i test del tempo di funzionamento tra i guasti. Il primo gruppo di test mostra quanto bene il sistema si ripristini da guasti software, guasti hardware. Il secondo gruppo di test determina il grado di stabilità del sistema durante il normale funzionamento e consente di stimare il tempo di attività del sistema. La suite di test di stabilità dovrebbe includere test che simulano il carico di picco sul sistema.

Quindi l'intero set di moduli viene sottoposto a un test di sistema: un test di accettazione interno del prodotto, che mostra il livello della sua qualità. Ciò include test di funzionalità e test di affidabilità del sistema.

L'ultimo test automatizzato sistema informativo- prove di accettazione. Tale test prevede la presentazione del sistema informativo al cliente e deve contenere un gruppo di test che simulino processi aziendali reali.

3.5 Messa in servizio del sistema

Nella fase di messa in esercizio dell'impianto vengono effettuati i test, il sistema viene testato in condizioni reali, sono in corso le trattative sui risultati del progetto e su eventuali nuovi contratti.

Principali tipologie di lavoro:

§ prove complesse;

§ formazione del personale per il funzionamento dell'impianto in corso di realizzazione;

§ preparazione della documentazione di lavoro, consegna dell'impianto al cliente e messa in esercizio;

§ accompagnamento, supporto, servizio;

§ valutazione dei risultati del progetto e preparazione dei documenti finali.

4. COMPOSIZIONE E STRUTTURA DEL COMPITO TECNICO E PROGETTAZIONE TECNICA

1. Disposizioni generali

1.1. Il capitolato d'oneri (TOR) è il documento principale che definisce i requisiti e la procedura per la creazione (sviluppo o ammodernamento - ulteriore creazione) del sistema informativo, in base al quale viene effettuato lo sviluppo del SI e la sua accettazione quando posta in funzione.

1.2. TK è sviluppato per il sistema nel suo insieme, progettato per funzionare in modo indipendente o come parte di un altro sistema.

1.3. I requisiti per IS nel volume stabilito da questo standard possono essere inclusi nell'incarico per la progettazione di un oggetto di informatizzazione di nuova creazione. In questo caso, il TK non è sviluppato.

1.4. I requisiti inclusi nel TK devono essere conformi all'attuale livello di sviluppo Tecnologie informatiche e non cedere a requisiti simili per le migliori controparti nazionali ed estere moderne. I requisiti fissati nel TK non dovrebbero limitare lo sviluppatore del sistema nella ricerca e nell'attuazione delle soluzioni tecniche, tecniche, economiche e di altro tipo più efficaci.

1.5. Il TK include solo quei requisiti che integrano i requisiti per i sistemi di questo tipo e sono determinati dalle specifiche di un particolare oggetto per il quale viene creato il sistema.

1.6. Le modifiche al TK sono redatte da un'aggiunta o da un protocollo firmato dal cliente e dallo sviluppatore. Il supplemento o il protocollo specificato è parte integrante del TK on IP. Sulla pagina del titolo del TK dovrebbe esserci una voce "Valido da ...".

2. Composizione e contenuto

2.1. Il TK contiene le seguenti sezioni, che possono essere suddivise in sottosezioni:

1) informazioni generali;

2) lo scopo e gli obiettivi della creazione (sviluppo) del sistema;

3) caratteristiche degli oggetti;

4) requisiti di sistema;

5) la composizione e il contenuto del lavoro sulla creazione del sistema;

6) la procedura di controllo e accettazione del sistema;

7) requisiti per la composizione e il contenuto del lavoro sulla preparazione dell'oggetto di sviluppo per la messa in funzione del sistema;

8) requisiti per la documentazione;

9) fonti di sviluppo.

TK può includere applicazioni.

2.2. A seconda del tipo, dello scopo, delle caratteristiche specifiche del progetto e delle condizioni per il funzionamento del sistema, è consentito formalizzare sezioni del TK sotto forma di domande, introdurre ulteriori, escludere o combinare sottosezioni del TK.

Il TK per parti del sistema non include sezioni che duplicano il contenuto delle sezioni TK nel suo insieme.

2.3. Nella sezione "Informazioni generali" indicare:

1) il nome completo del sistema e il suo simbolo;

2) il codice dell'argomento o il codice (numero) del contratto;

3) il nome delle società dello sviluppatore e del cliente (utente) del sistema e i loro dettagli;

4) un elenco dei documenti in base ai quali è stato creato il sistema, da chi e quando tali documenti sono stati approvati;

5) le date di inizio e fine previste per la realizzazione del sistema;

6) informazioni sulle fonti e modalità di finanziamento dell'opera;

7) la procedura per la registrazione e la presentazione al cliente dei risultati del lavoro sulla creazione del sistema (le sue parti), sulla fabbricazione e regolazione dei singoli mezzi (hardware, software, informazioni) e software e hardware (software e metodologico ) sistemi del sistema.

2.4. La sezione "Scopo e obiettivi della creazione (sviluppo) del sistema" è composta da sottosezioni:

1) lo scopo del sistema;

2) lo scopo della creazione del sistema.

2.4.1. Nella sottosezione "Finalità del sistema" indicare il tipo di attività del sistema (gestione, progettazione, ecc.) e l'elenco degli oggetti di informatizzazione (oggetti) su cui si suppone che venga utilizzato.

2.4.2. Nella sottosezione "Gli obiettivi della creazione di un sistema", vengono forniti i nomi e i valori richiesti degli indicatori tecnici, tecnologici, produttivi-economici o di altro tipo dell'oggetto dell'informatizzazione, che devono essere raggiunti a seguito della creazione di un SI , e sono indicati i criteri per valutare il raggiungimento degli obiettivi di realizzazione di un sistema.

2.5. Nella sezione "Caratteristiche dell'oggetto dell'informatizzazione" indicare:

1) brevi informazioni sull'oggetto dell'informatizzazione o collegamenti a documenti contenenti tali informazioni;

2) informazioni sulle condizioni di funzionamento dell'oggetto automazione.

2.6. La sezione Requisiti di sistema è composta dalle seguenti sottosezioni:

1) requisiti per il sistema nel suo insieme;

2) requisiti per le funzioni (compiti) svolte dal sistema;

3) requisiti per i tipi di sicurezza.

La composizione dei requisiti per il sistema, inclusi in questa sezione del TK per IS, è stabilita in base al tipo, allo scopo, alle caratteristiche specifiche e alle condizioni di funzionamento di un particolare sistema.

2.6.1. Nella sottosezione "Requisiti per l'intero sistema" indicare:

requisiti per la struttura e il funzionamento del sistema;

requisiti per il numero e le qualifiche del personale del sistema e le modalità del loro lavoro;

indicatori di destinazione;

requisiti di affidabilità;

Requisiti di sicurezza;

requisiti di ergonomia ed estetica tecnica;

requisiti per il funzionamento, la manutenzione, la riparazione e lo stoccaggio dei componenti del sistema;

requisiti per la protezione delle informazioni da accessi non autorizzati;

requisiti per la sicurezza delle informazioni in caso di incidenti;

requisiti per la protezione dall'influenza di influenze esterne;

requisiti per la purezza del brevetto;

requisiti per la standardizzazione e l'unificazione;

Requisiti addizionali.

2.6.1.1. I requisiti per la struttura e il funzionamento del sistema includono:

1) un elenco di sottosistemi, il loro scopo e le caratteristiche di base, i requisiti per il numero di livelli di gerarchia e il grado di centralizzazione del sistema;

2) requisiti per metodi e mezzi di comunicazione per lo scambio di informazioni tra componenti del sistema;

3) requisiti per le caratteristiche delle interconnessioni del sistema in corso di realizzazione con sistemi adiacenti, requisiti per la sua compatibilità, comprese le istruzioni sulle modalità di scambio delle informazioni (automaticamente, mediante invio di documenti, per telefono, ecc.);

4) requisiti per le modalità di funzionamento del sistema;

5) requisiti per la diagnosi del sistema;

6) prospettive di sviluppo, ammodernamento del sistema.

2.6.1.2. I requisiti per il numero e le qualifiche del personale IS includono:

§ requisiti per il numero di personale (utenti) di IS;

§ requisiti per le qualifiche del personale, procedura per la loro formazione e controllo delle conoscenze e competenze;

§ modalità di lavoro richiesta al personale IS.

2.6.1.3. Nei requisiti per gli indicatori dello scopo dell'IS, sono riportati i valori dei parametri che caratterizzano il grado di conformità del sistema al suo scopo.

2.6.1.4. I requisiti di affidabilità includono:

1) la composizione e i valori quantitativi degli indicatori di affidabilità per il sistema nel suo insieme o i suoi sottosistemi;

2) un elenco delle situazioni di emergenza per le quali devono essere regolamentati i requisiti di affidabilità e i valori degli indicatori corrispondenti;

3) requisiti per l'affidabilità dell'hardware e del software;

4) requisiti per le modalità di valutazione e monitoraggio degli indicatori di affidabilità nelle diverse fasi della realizzazione del sistema in conformità ai documenti normativi e tecnici vigenti.

2.6.1.5. I requisiti di sicurezza includono i requisiti di sicurezza per la consegna, la messa in servizio, il funzionamento e la manutenzione del sistema.

2.6.1.6. I requisiti per l'ergonomia e l'estetica tecnica includono indicatori IP che stabiliscono la qualità richiesta dell'interazione uomo-macchina e il comfort delle condizioni di lavoro per il personale.

2.6.1.7. I requisiti per la protezione delle informazioni dall'accesso non autorizzato includono i requisiti stabiliti dal settore e dall'ambiente informativo del cliente.

2.6.1.8. Nei requisiti per la sicurezza delle informazioni viene fornito un elenco di eventi: incidenti, guasti dei mezzi tecnici (compresa la perdita di potenza), ecc., In cui deve essere garantita la sicurezza delle informazioni nel sistema.

2.6.1.9. I requisiti per la purezza del brevetto indicano un elenco di paesi rispetto ai quali deve essere garantita la purezza del brevetto del sistema e delle sue parti.

2.6.1.10. I requisiti aggiuntivi includono requisiti speciali a discrezione dello sviluppatore o del cliente del sistema.

2.6.2. Nella sottosezione "Requisiti per le funzioni (compiti)" svolte dal sistema, sono riportati:

§ per ciascun sottosistema, un elenco di funzioni, compiti o loro complessi (compresi quelli che garantiscono l'interazione di parti del sistema) da automatizzare;

§ quando si crea un sistema in due o più code - un elenco di sottosistemi funzionali, singole funzioni o attività che vengono messe in funzione nella 1a e nelle successive code;

§ tempistica per l'attuazione di ciascuna funzione, compito (o insieme di compiti);

§ requisiti per la qualità dell'implementazione di ciascuna funzione (compito o complesso di compiti), per la forma di presentazione delle informazioni di output, caratteristiche dell'accuratezza richiesta e tempo di esecuzione, requisiti per l'esecuzione simultanea di un gruppo di funzioni, l'affidabilità dei risultati;

§ un elenco e criteri di guasti per ciascuna funzione, per i quali sono fissati requisiti di affidabilità.

2.6.3. Nella sottosezione "Requisiti per i tipi di supporto", a seconda del tipo di sistema, vengono forniti i requisiti per il supporto di sistema matematico, informativo, linguistico, tecnico, metrologico, organizzativo, metodologico e di altro tipo.

2.6.3.2. Per il supporto informativo del sistema sono previsti i seguenti requisiti:

1) alla composizione, struttura e modalità di organizzazione dei dati nel sistema;

2) scambio di informazioni tra i componenti del sistema;

3) compatibilità delle informazioni con i relativi sistemi;

4) sull'applicazione dei sistemi di gestione di basi di dati;

5) alla struttura del processo di raccolta, elaborazione, trasferimento dei dati nel sistema e presentazione dei dati;

6) alla protezione dei dati;

7) controllo, conservazione, aggiornamento e recupero dei dati;

2.6.3.3. Per il supporto linguistico del sistema, vengono forniti i requisiti per l'uso di linguaggi di programmazione di alto livello nel sistema, linguaggi per l'interazione tra utenti e mezzi tecnici del sistema, nonché requisiti per la codifica e la decodifica dei dati, per linguaggi di input-output di dati, linguaggi di manipolazione dei dati, mezzi per descrivere l'area disciplinare, per metodi che organizzano un dialogo.

2.6.3.4. Per il software del sistema viene fornito un elenco dei software acquistati, nonché i requisiti:

1) alla dipendenza del software dall'ambiente operativo;

2) alla qualità del software, nonché alle modalità della sua fornitura e controllo;

2.6.3.5. Per il supporto tecnico del sistema sono previsti i seguenti requisiti:

1) ai tipi di mezzi tecnici, compresi i tipi di complessi di mezzi tecnici, complessi software e hardware e altri componenti, ammissibili per l'uso nel sistema;

2) alle caratteristiche funzionali, progettuali e operative del supporto tecnico del sistema.

2.6.3.6. I requisiti per il supporto metrologico includono:

1) un elenco preliminare dei canali di misura;

2) requisiti per l'accuratezza delle misurazioni dei parametri e (o) per le caratteristiche metrologiche dei canali di misurazione;

3) requisiti per la compatibilità metrologica dei mezzi tecnici del sistema;

4) un elenco dei canali di controllo e di calcolo del sistema per i quali è necessario valutare le caratteristiche di accuratezza;

5) requisiti per il supporto metrologico dell'hardware e del software che fanno parte dei canali di misura del sistema, mezzi, controllo integrato, idoneità metrologica dei canali di misura e degli strumenti di misura utilizzati nella messa a punto e nel collaudo del sistema;

6) il tipo di certificazione metrologica (statale o dipartimentale) con l'indicazione della procedura per la sua attuazione e delle organizzazioni che effettuano la certificazione.

2.6.3.7. Per il supporto organizzativo vengono forniti i requisiti:

1) alla struttura e alle funzioni delle unità coinvolte nel funzionamento del sistema o che ne forniscono il funzionamento;

2) all'organizzazione del funzionamento del sistema e all'ordine di interazione tra il personale IS e il personale dell'oggetto dell'informatizzazione;

3) per proteggere da azioni errate del personale del sistema.

2.7. La sezione "Composizione e contenuto del lavoro sulla creazione (sviluppo) del sistema" dovrebbe contenere un elenco di fasi e fasi di lavoro sulla creazione del sistema, i tempi della loro attuazione, un elenco di organizzazioni - esecutori del lavoro , collegamenti a documenti che confermano il consenso di queste organizzazioni a partecipare alla creazione del sistema o un record che identifica la persona responsabile (cliente o sviluppatore) per l'esecuzione di questi lavori.

Questa sezione fornisce inoltre:

1) un elenco dei documenti presentati al termine delle relative fasi e fasi di lavoro;

2) il tipo e la procedura per l'esame della documentazione tecnica (fase, fase, volume della documentazione verificata, organizzazione di esperti);

3) un programma di lavoro volto a garantire il livello di affidabilità richiesto del sistema in fase di sviluppo (se necessario);

4) un elenco dei lavori di supporto metrologico in tutte le fasi della creazione del sistema, indicando le loro scadenze e le organizzazioni esecutive (se necessario).

2.8. Nella sezione "Procedura per il controllo e l'accettazione del sistema" indicare:

1) tipologie, composizione, ambito e metodi di prova del sistema e dei suoi componenti;

2) requisiti generali per l'accettazione dei lavori per fasi, la procedura per il coordinamento e l'approvazione della documentazione di accettazione;

2.9. Nella sezione "Requisiti per la composizione e il contenuto del lavoro sulla preparazione dell'oggetto di automazione per la messa in servizio del sistema", è necessario fornire un elenco delle attività principali e dei loro esecutori che dovrebbero essere eseguite durante la preparazione del progetto per la messa in servizio dell'IS.

L'elenco delle principali attività comprende:

1) portare le informazioni in ingresso a sistema (nel rispetto delle prescrizioni in materia di informazione e supporto linguistico);

2) creazione di condizioni per il funzionamento del progetto, in base alle quali sia garantita la conformità del sistema creato ai requisiti contenuti nel TOR;

3) creazione di unità e servizi necessari al funzionamento del sistema;

4) i tempi e le modalità di assunzione e formazione del personale.

2.10. Nella sezione "Requisiti per la documentazione" sono indicati:

1) l'elenco degli insiemi e dei tipi di documenti da sviluppare, concordato tra lo sviluppatore e il Cliente del sistema;

2) un elenco dei documenti emessi sui supporti della macchina;

3) in assenza di standard statali che determinano i requisiti per la documentazione degli elementi del sistema, includere inoltre i requisiti per la composizione e il contenuto di tali documenti.

2.11. La sezione "Fonti di sviluppo" dovrebbe elencare i documenti e i materiali informativi sulla base dei quali è stato sviluppato il TK e che dovrebbero essere utilizzati durante la creazione del sistema.

3. Regole di progettazione.

3.1. Sezioni e sottosezioni del TK devono essere disposte nell'ordine stabilito nella sezione. 2 di questa norma.

3.2. I numeri dei fogli (pagine) sono riportati, a partire dal primo foglio successivo al frontespizio, nella parte superiore del foglio (sopra il testo, al centro) dopo la designazione del codice TK sull'IP.

3.3. Il frontespizio contiene le firme del cliente, dello sviluppatore e delle società di approvazione, che sono sigillate. Se necessario, il frontespizio è redatto su più pagine. Le firme degli sviluppatori e dei funzionari TK che partecipano all'approvazione e all'esame della bozza di TK sull'IP sono poste sull'ultimo foglio.

La forma del frontespizio del TK è fornita nell'Appendice 2. La forma dell'ultima pagina del TK è data nell'Appendice 3.

3.4. Il frontespizio dell'aggiunta al TK è redatto allo stesso modo del frontespizio dell'incarico tecnico. Invece del nome "Termini di riferimento" scrivono "Supplemento n. ... al TOR per AC ...".

3.5. Nei fogli successivi dell'aggiunta al TK, vengono inseriti la base per la modifica, il contenuto della modifica e i collegamenti ai documenti, in base ai quali vengono apportate tali modifiche.

3.6. Nel presentare il testo del supplemento al TK, dovrebbero essere indicati i numeri delle clausole, sottoclausole, tabelle del TK principale, ecc. " dovrebbe essere usato.

La procedura per lo sviluppo, il coordinamento e l'approvazione di TK for IP.

1. Il progetto TK è sviluppato dall'organizzazione-sviluppatore del sistema con la partecipazione del cliente sulla base dei requisiti tecnici (applicazioni, specifiche tattiche e tecniche, ecc.).

Nell'organizzazione competitiva del lavoro, le opzioni per il progetto TK sono considerate dal cliente, che sceglie l'opzione preferita o, sulla base di un'analisi comparativa, prepara la versione finale del TK per AC con la partecipazione del futuro sviluppatore IS.

2. La necessità di approvazione del progetto TK con le autorità di supervisione statale e altre organizzazioni interessate è determinata congiuntamente dal cliente del sistema e dallo sviluppatore del progetto TK sull'IS,

Il lavoro sull'approvazione del progetto di TK per l'IC è svolto congiuntamente dallo sviluppatore del TK e dal cliente del sistema, ciascuno nelle organizzazioni del proprio ministero (dipartimento).

3. Il termine di approvazione del progetto TK in ciascuna organizzazione non deve superare i 15 giorni dalla data di ricezione. Si consiglia di inviare copie della bozza TK (copie) contemporaneamente a tutte le organizzazioni (divisioni) per l'approvazione.

4. I commenti sul progetto di RPT devono essere presentati con una giustificazione tecnica. Le decisioni sui commenti dovrebbero essere prese dallo sviluppatore del progetto TK e dal cliente del sistema prima dell'approvazione del TK sull'IS.

5. Se, al momento dell'accordo sulla bozza TK, sono sorti disaccordi tra lo sviluppatore e il cliente (o altre organizzazioni interessate), viene redatto un protocollo di disaccordo (forma arbitraria) e viene presa una decisione specifica in ordine stabilito.

6. L'approvazione del progetto TK è consentita per redigere un documento separato (lettera). In questo caso, sotto la voce "Accettato" creare un collegamento a questo documento.

7. L'approvazione del TK è effettuata dai responsabili delle società dello sviluppatore e del cliente del sistema.

8. Copie del TK approvato entro 10 giorni dall'approvazione vengono inviate dallo sviluppatore del TK ai partecipanti alla creazione del sistema.

9. Il coordinamento e l'approvazione delle integrazioni a TK sono effettuati secondo le modalità stabilite per TK su IP.

10. Le modifiche al TK non possono essere approvate dopo l'invio del sistema o la sua coda per i test di accettazione.

La base per lo sviluppo del progetto tecnico del sistema è l'incarico tecnico approvato dal cliente.

La progettazione tecnica del sistema è una documentazione tecnica approvata nel modo prescritto, contenente soluzioni progettuali a livello di sistema, un algoritmo per la risoluzione dei problemi, nonché una valutazione dell'efficienza economica di un sistema di controllo automatizzato e un elenco di misure per preparare un oggetto per l'attuazione.

Il progetto tecnico è in fase di sviluppo al fine di determinare le principali soluzioni progettuali per la realizzazione dell'impianto. In questa fase viene svolto un complesso di lavoro di ricerca e sperimentazione per selezionare migliori opzioni soluzioni, si esegue una verifica sperimentale delle principali soluzioni progettuali e il calcolo dell'efficienza economica del sistema.

Il progetto tecnico contiene infatti un complesso di modelli economici, matematici e algoritmici.

Un set completo di progettazione tecnica per il sistema include 10 documenti:

1. Nota esplicativa.

2. Struttura funzionale e organizzativa del sistema.

3. Enunciato del problema e algoritmo risolutivo.

4. Organizzazione della base informativa.

5. Album di moduli di documenti.

6. Sistema software.

7. Il principio della costruzione di un complesso di mezzi tecnici.

8. Calcolo dell'efficienza economica del sistema.

9. Misure per preparare l'impianto per l'attuazione del sistema.

10. Elenco dei documenti.

Dall'elenco di cui sopra, il documento 3 "Dichiarazione dei compiti e l'algoritmo per la risoluzione" viene eseguito per ogni singolo compito incluso nell'EIS, il resto dei documenti è comune per l'intero sistema. Inoltre, i documenti 1, 2, 5, 8 e 9 possono essere sviluppati per singoli sottosistemi.

Tutti i documenti elencati possono essere raggruppati e presentati sotto forma di quattro parti principali di un progetto tecnico: economico e organizzativo, informativo, matematico e tecnico.

La parte economica e organizzativa del progetto tecnico contiene una nota esplicativa che giustifica lo sviluppo del sistema, un elenco delle organizzazioni degli sviluppatori, una breve descrizione dell'oggetto che indica i principali indicatori tecnici ed economici del suo funzionamento e le connessioni con altri oggetti, brevi informazioni sulle principali soluzioni progettuali per le parti funzionali e portanti del sistema.

Nella sezione del progetto tecnico, dedicata alla struttura organizzativa e funzionale del sistema, sono riportate: le motivazioni dei sottosistemi allocati, il loro elenco e le finalità; un elenco di compiti da risolvere in ciascun sottosistema, con una breve descrizione del loro contenuto; un diagramma dei collegamenti informativi tra i sottosistemi e tra le attività all'interno di ciascun sottosistema.

Per ogni attività inclusa nell'insieme delle attività prioritarie, vengono eseguite la sua dichiarazione e l'algoritmo per risolverla. Questa sezione del disegno tecnico comprende:

§ l'essenza organizzativa ed economica del problema (nome, scopo della soluzione, sintesi, metodo, frequenza e tempo di risoluzione del problema, metodi di raccolta e trasferimento dei dati, collegamento del problema con altri problemi, natura dell'utilizzo dei risultati di la soluzione in cui vengono utilizzati);

§ modello economico e matematico del problema (forma di presentazione strutturale e di dettaglio);

§ inserire informazioni operative (caratteristiche degli indicatori, loro significato e portata di variazione, modulistica di presentazione);

§ Informazioni di riferimento normativo (NSI) - contenuto e forme di presentazione;

§ informazioni memorizzate per la comunicazione con altre attività;

§ informazioni accumulate per successive soluzioni a questo problema;

§ informazioni sulle modifiche (sistema per le modifiche e elenco delle informazioni soggette a modifiche);

§ algoritmo per la risoluzione del problema (sequenza di fasi di calcolo, diagramma, formule di calcolo);

§ test case (un insieme di moduli di documenti di input pieni di dati, documenti condizionali con informazioni accumulate e archiviate, moduli di documenti di output completati in base ai risultati della risoluzione di un problema economico e tecnico e in conformità con l'algoritmo di calcolo sviluppato).

Il documento "Calcolo dell'efficienza economica dell'impianto" contiene una stima consolidata dei costi connessi all'esercizio degli impianti, viene fornito il calcolo dell'efficienza economica annuale, le cui fonti sono l'ottimizzazione della struttura produttiva del economia (associazione), la riduzione dei costi di produzione dovuta all'uso razionale delle risorse produttive e la riduzione delle perdite, le decisioni gestionali.

Il documento "Misure per preparare l'impianto per l'attuazione del sistema" contiene un elenco di misure organizzative per migliorare la struttura di gestione esistente, un elenco di lavori sull'attuazione del sistema che devono essere eseguiti nella fase di progettazione dettagliata, indicando i tempi e le persone responsabili.

La parte informativa del progetto tecnico unisce i documenti 4 e 5. Il documento "Organizzazione della base informativa" riflette: fonti di informazione e metodi della sua trasmissione per risolvere il complesso primario di compiti funzionali; un insieme di indicatori utilizzati nel sistema; composizione degli atti, termini e periodicità della loro ricezione; soluzioni progettuali di base per l'organizzazione del fondo INS; composizione dell'INS, compreso l'elenco dei dettagli, la loro definizione, il significato, la gamma di modifiche e l'elenco dei documenti dell'INS; elenco delle serie di dati di riferimento, loro volume, ordine e frequenza di correzione delle informazioni; proposte per l'unificazione della documentazione, un banco di prova per la modifica del NSI; forma strutturale di NSI con descrizione della relazione tra gli elementi; requisiti per la tecnologia di creazione e mantenimento del fondo; modalità di conservazione, ricerca, modifica e controllo, determinazione dei volumi e dei flussi informativi dei dati di riferimento.

"Album di forme di documenti" contiene forme di dati di riferimento.

La parte matematica del progetto tecnico contiene le motivazioni per la struttura del software, le motivazioni per la scelta del sistema di programmazione, compreso l'elenco dei programmi standard.

La parte tecnica del progetto tecnico comprende: descrizione e giustificazione dello schema del processo di elaborazione dei dati tecnici; giustificazione dei requisiti per lo sviluppo di apparecchiature non standard; fondatezza e scelta della struttura del complesso dei mezzi tecnici e dei suoi gruppi funzionali; una serie di misure per garantire l'affidabilità del funzionamento dei mezzi tecnici.

CONCLUSIONE

Lo sviluppo di un sistema informativo, di regola, viene effettuato per abbastanza un'impresa specifica... Le specificità dell'attività in oggetto dell'impresa, ovviamente, influenzano la struttura del sistema informativo, ma allo stesso tempo le strutture delle diverse imprese sono generalmente simili tra loro. Ogni organizzazione, indipendentemente dal tipo di attività, è costituita da una serie di divisioni che svolgono direttamente l'uno o l'altro tipo di attività aziendale, e questa situazione è vera per quasi tutte le organizzazioni, indipendentemente dal tipo di attività in cui sono impegnate.

L'introduzione di moderne tecnologie dell'informazione consente di ridurre i tempi necessari per la preparazione di specifici progetti di marketing e produzione, ridurre i costi non produttivi durante la loro attuazione, eliminare la possibilità di errori nella preparazione della documentazione contabile, tecnologica e di altro tipo, che conferisce a una società commerciale un effetto economico diretto.

Naturalmente, al fine di svelare tutte le potenziali possibilità che l'uso dei computer comporta, è necessario utilizzare nel proprio lavoro un insieme di strumenti software e hardware che meglio si adattano ai compiti impostati. Pertanto, attualmente, c'è un grande bisogno di società commerciali in programmi per computer che supportano il lavoro del management aziendale, nonché informazioni su come utilizzare al meglio le apparecchiature informatiche aziendali.

L'implementazione della progettazione AIS comporta l'uso di una determinata tecnologia di progettazione da parte dei progettisti, corrispondente alla scala e alle caratteristiche del progetto in fase di sviluppo.

ELENCO DELLA LETTERATURA USATA

1. Linee guida per lo studio della disciplina "Sistemi informativi automatizzati" [ Risorsa elettronica]. - Mosca, 2006. - Modalità di accesso:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Titolo. dallo schermo.

2. Wikipedia, l'enciclopedia libera [Risorsa elettronica] / Articolo "Sistema informativo" - Modalità di accesso: http://ru.wikipedia.org/wiki/Sistema informativo.

3. Stampa computerizzata: rivista Internet. - Elettrone. Dan. - [Bm, 2001]. - Modalità di accesso: http://compress.ru/article.aspx?id=12282.

4. Vendrov AM, "Progettazione di software per sistemi informativi economici" / .М. Vendra. - M.: "Finanza e statistica", 2000. - 364 p.

5. "Termini di riferimento per la creazione di un sistema automatizzato" / - M .: GOST 34.602-89, 1990.

6. Grekul V.I. "Progettare sistemi informativi" / V.I. Grekul, G.N. Denischenko, N.L. Korovkin. - M.: Internet University of Information Technologies, 2008.

Pubblicato su Allbest.ru

Documenti simili

Sviluppo di sistemi informativi. Mercato moderno software applicato finanziario ed economico. Vantaggi e svantaggi dell'implementazione di sistemi informativi automatizzati. Metodi per la progettazione di sistemi informativi automatizzati.

tesi, aggiunta 22/11/2015


Tipi di supporto per sistemi informativi automatizzati. Preparazione di specifiche tecniche, sviluppo di un sistema informativo, preparazione di un manuale utente per il programma. Strumenti di programmazione per sistemi di elaborazione delle informazioni distribuite.

rapporto di pratica, aggiunto il 16/04/2017


Ciclo di vita dei sistemi informativi automatizzati. Fondamenti di metodologia per la progettazione di sistemi automatizzati basati su tecnologie CASE. La fase di analisi e progettazione, costruzione e implementazione di un sistema automatizzato. Cascata e modello a spirale.

tesina, aggiunta il 20/11/2010


Il concetto di sistema informativo, tipi di sistemi informativi. Analisi di strumenti per lo sviluppo di sistemi informativi automatizzati. Requisiti per il programma e il prodotto software. Sviluppo di forme di interfaccia grafica e database.

tesi, aggiunta il 23/06/2015


I principi di organizzazione di un sistema composto da personale e un insieme di strumenti per automatizzare le loro attività. Progettazione di sistemi informativi aziendali automatizzati. Struttura, flussi di input e output, limiti dei sistemi automatizzati.

presentazione aggiunta il 14/10/2013


Concetto di sistema informativo. Fasi di sviluppo dei sistemi informativi. Processi nel sistema informativo. Sistema informativo per la ricerca di nicchie di mercato, per la riduzione dei costi di produzione. La struttura del sistema informativo. Supporto tecnico.

abstract, aggiunto il 17/11/2011


Organizzazione, architettura e struttura del sistema informativo. Indicatori dell'efficacia del suo lavoro. Scopi e obiettivi dell'analisi di ACS. Componenti di sistemi automatizzati. Descrizione dell'area disciplinare, dati di input e output. Costruire un diagramma dei casi d'uso.

tesina aggiunta il 04/11/2014


Creazione e organizzazione di sistemi informativi automatizzati (AIS). Principali componenti e processi tecnologici dell'AIS. Fasi e fasi della creazione dell'AIS dalla posizione del management dell'organizzazione. Sviluppo di complessi di soluzioni progettuali per un sistema automatizzato.

abstract, aggiunto il 18/10/2012


I principali fattori che hanno influenzato la storia dello sviluppo dei sistemi informativi automatizzati aziendali. I loro caratteristiche generali e classificazione. Composizione e struttura dell'AIS integrato. I sistemi ERP come una moderna tipologia di sistema informativo aziendale.

presentazione aggiunta il 14/10/2013


Analisi dell'area disciplinare, fasi di progettazione di sistemi informativi automatizzati. Sistemi di strumenti di sviluppo software. Il ruolo degli strumenti CASE nella progettazione del modello informativo. Modello logico del database progettato.

Il 1 dicembre 2015 si è svolta una difesa aperta del sistema informativo di gestione dei progetti automatizzato (AIS PU) creato dall'ordine del Ministero dell'Industria e del Commercio della Russia. Alla difesa, presieduta dal Primo Vice Ministro dell'Industria e del Commercio della Federazione Russa Gleb Nikitin, hanno partecipato i capi di dipartimento del Ministero, rappresentanti del Ministero sviluppo economico e il Ministero della Difesa della Federazione Russa.

Il sistema automatizzato di gestione dei progetti è progettato per migliorare l'efficienza del Ministero dell'Industria e del Commercio della Russia in termini di supporto, manutenzione e attuazione di progetti volti, tra l'altro, alla sostituzione delle importazioni, all'aumento delle esportazioni, allo sviluppo tecnologico della produzione, alla creazione e ammodernamento di posti di lavoro ad alto rendimento e sviluppo di infrastrutture industriali (parchi industriali, parchi tecnologici, centri di design industriale e ingegneria).

I principali utenti del sistema creato, insieme alla leadership e ai dipendenti del ministero responsabile dell'attuazione dei programmi statali e federali programmi mirati, saranno le imprese industriali che attuano i propri progetti di investimento, organi federali ramo esecutivo che fornisce sostegno statale a imprese, banche, investitori istituzionali e altre istituzioni finanziarie coinvolte nel finanziamento di progetti di investimento imprese industriali e progetti di sviluppo di infrastrutture industriali.

Il sistema è stato creato dall'integratore di sistemi russo "Inline-Technologies" con il coinvolgimento dello sviluppatore di software domestico "LM-Soft". AIS PU è stato sviluppato sulla base della piattaforma russa 1C utilizzando software libero e software proprietario.

Sulla base dei risultati dello studio della funzionalità del sistema, è stato ricevuto un feedback positivo sia dalla direzione e dai dipendenti del Ministero dell'Industria e del Commercio, sia dal Ministero dello Sviluppo Economico, che è responsabile dell'attuazione dei meccanismi di gestione dei progetti nel governo corpi. Inoltre, un feedback positivo sulle capacità di AIS PU è stato fornito dalle imprese industriali che hanno presentato i loro progetti pilota nell'ambito dello sviluppo del sistema. In particolare, i rappresentanti della FSUE "Krylov State centro scientifico", JSC" Società scientifica e di produzione "Uralvagonzavod", Impresa statale federale "Istituto di ricerca scientifica" Geodesia ". Va inoltre notato che rappresentanti di Garrison JSC, che è sotto la giurisdizione del Ministero della Difesa, nonché rappresentanti di alcune banche a partecipazione statale, hanno mostrato vivo interesse per il sistema e interesse per una cooperazione congiunta nell'attuazione della gestione del progetto .

“Il sistema di gestione dei progetti creato non solo aumenterà l'efficienza dei dipendenti del ministero, ma consentirà anche di organizzare un'interazione efficace con i partecipanti a progetti industriali di imprese industriali, enti governativi e istituzioni di sviluppo e istituzioni finanziarie. AIS PU opera secondo il principio di uno "sportello unico" con il massimo utilizzo delle tecnologie di gestione elettronica dei documenti ", ha commentato Sergei Valuev, Direttore del Dipartimento delle tecnologie dell'informazione e delle relazioni pubbliche del Ministero dell'Industria e del Commercio, sull'attuazione del sistema.

“L'obiettivo principale dell'introduzione di AIS PU è migliorare la qualità del controllo e della gestibilità, per facilitare l'interazione tra autorità ed esecutori di progetti su larga scala. Nello sviluppo del sistema si è tenuto conto innanzitutto delle norme di settore, dei decreti e delle ordinanze del Governo, dei decreti del Presidente e delle ordinanze del Ministro dell'Industria e del Commercio, nonché delle migliori prassi nazionali ed estere. Sono stati progettati più di 600 componenti per AIS PU, sono stati caricati più di 20.000 libri di riferimento, dizionari e classificatori. Nell'ambito di ulteriori lavori sullo sviluppo di AIS PU, si prevede di integrare il sistema come uno dei sottosistemi del Sistema informativo statale dell'industria attualmente in fase di creazione da parte del Ministero dell'Industria e del Commercio della Russia ", ha affermato Sergey Valuev.

L'introduzione delle modalità di project management è definita come uno dei principali strumenti di modernizzazione della pubblica amministrazione ed è sancita dalla nuova edizione dei "Principali indirizzi di attività del Governo della Federazione Russa per il periodo fino al 2018", firmata dal Primo Ministro Ministro Dmitry Medvedev.