LA CAMPANA

C'è chi ha letto questa notizia prima di te.
Iscriviti per ricevere gli ultimi articoli.
E-mail
Nome
Cognome
Come vuoi leggere The Bell
Niente spam

introduzione

La tesi in esame è stata scritta sulla base di Donetsk OJSC Donetsk Manufactory per il negozio Cleonelly.

Una delle attività principali della Manifattura di Donetsk OJSC produce una vasta gamma di indumenti, principalmente accappatoi, lenzuola e asciugamani. L'azienda produce inoltre filati di cotone tinto per tessitura e maglieria.

Sviluppo di automatizzato tecnologie informatiche va in parallelo con l'emergere di nuovi tipi di mezzi tecnici di elaborazione e trasmissione di informazioni, miglioramento delle forme organizzative di utilizzo dei computer, saturazione dell'infrastruttura con nuovi mezzi di comunicazione. Lo sviluppo delle relazioni di mercato ha portato alla nascita di nuove tipologie di attività imprenditoriale e, soprattutto, alla creazione di imprese impegnate nel business dell'informazione, allo sviluppo delle tecnologie dell'informazione, al loro miglioramento, alla diffusione di componenti di tecnologie informatiche automatizzate, in particolare prodotti software che automatizzano i processi informativi e informatici. Includono anche apparecchiature informatiche, strutture di comunicazione, apparecchiature per ufficio e tipi specifici di servizi: informazioni, servizi tecnici e di consulenza, formazione, ecc. Ciò ha contribuito alla rapida diffusione e all'uso efficace delle tecnologie dell'informazione nei processi di gestione e produzione, quasi al loro uso onnipresente e alla loro grande diversità.

Le aziende impegnate nella progettazione e nello sviluppo di dispositivi per vari scopi attualmente utilizzano ampiamente vari mezzi di progettazione assistita da computer - CAD (CAD) e monitoraggio dei processi di produzione - ACS (SCADA / DCS). Tuttavia, per i dispositivi di nostra progettazione, è necessario sviluppare fondi propri controllo delle loro prestazioni e analisi della qualità del prodotto.

Il processo tecnologico di contabilizzazione dei prodotti in un magazzino in un negozio Cleanelly include la fase di registrazione dei prodotti venduti.

Lo scopo del presente progetto di diploma è l'implementazione di una workstation automatizzata (AWP) che consente la contabilizzazione dei prodotti in un magazzino di un punto vendita.

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

¾ analizzare i processi aziendali del negozio;

¾ esplora flussi di informazioniinsorgere nella fase di consegna del prodotto in fase di sviluppo;

¾ sviluppare modelli di dati concettuali e logici;

¾ sviluppare software per workstation automatizzate per la contabilità dei prodotti

¾ valutare l'efficienza economica del sistema informativo.

1 Sviluppo dei requisiti software

1.1 Analisi delle soluzioni esistenti

Attualmente, esiste una vasta gamma di aziende che combinano sia lo sviluppo diretto del prodotto che lo sviluppo di sistemi di controllo per questi prodotti. Tali sistemi vengono sviluppati da aziende famose come 1: C Enterprise e Zvezda. In tali sistemi, viene effettuato il controllo e la contabilità dei materiali e l'elaborazione delle informazioni ricevute.

"1C: Enterprise" è un sistema di soluzioni applicate costruito sugli stessi principi e su un'unica piattaforma tecnologica. Il manager può scegliere una soluzione che soddisfi le esigenze attuali dell'azienda e che si svilupperà ulteriormente con la crescita dell'azienda o con l'espansione delle attività di automazione.

Il sistema software 1C: Enterprise è progettato per risolvere un'ampia gamma di attività di contabilità e automazione gestionale che devono affrontare le aziende moderne in via di sviluppo dinamico. Soluzione di problemi urgenti di contabilità e gestione La composizione dei programmi del sistema 1C: Enterprise è focalizzata sulle reali esigenze delle imprese. L'azienda "1C" produce soluzioni software serializzate progettate per automatizzare le tipiche attività di contabilità e gestione delle imprese. Caratteristica distintiva delle soluzioni di produzione 1C è un attento studio della composizione delle funzionalità incluse nelle soluzioni standard. L'azienda "1C" analizza l'esperienza degli utenti che utilizzano i programmi del sistema "1C: Enterprise" e monitora i cambiamenti nelle loro esigenze.

I principali vantaggi del mio sistema Wholesale Base includono il relativo basso costo di implementazione questo sistema e anche una serie di altri vantaggi:

¾ Affidabilità applicazioni create... Il pacchetto software (PC) deve essere resistente non solo agli errori dell'utente, ma anche ai guasti nel sistema di comunicazione.

¾ Facilità di utilizzo dell'interfaccia;

¾ Elevato livello di sicurezza del sistema, che implica non solo il controllo sulla disponibilità di determinate risorse di sistema e la sicurezza delle informazioni in tutte le fasi operative, ma anche il monitoraggio delle azioni eseguite con un alto grado di affidabilità.

1.2 Analisi del dominio

La particolarità dell'analisi dell'area tematica è che permette di vedere l'intero insieme delle operazioni dell'organizzazione.

CASE è progettato per analizzare e riorganizzare i processi aziendali. Tutti gli strumenti di primo livello Fusion Process Modeler (BPwin) che supportano le metodologie IDEF0 (Functional Model), DFD (Dataflow Diagram) e IDEF3 (Workflow Diagram). BPwin è un potente prodotto software per la creazione di modelli per l'analisi, la documentazione e la pianificazione dei cambiamenti in processi aziendali complessi. BPwin offre uno strumento per raccogliere tutte le informazioni necessarie sul funzionamento dell'impresa e immagine grafica queste informazioni sotto forma di un modello olistico e coerente.

In termini di funzionalità del sistema. Nell'ambito della metodologia IDEF0 (Integration Definition for Function Modeling), un processo aziendale è rappresentato come un insieme di elementi di lavoro che interagiscono tra loro e vengono mostrate le informazioni, le risorse umane e di produzione consumate da ciascuna opera. Il modello funzionale è progettato per descrivere i processi aziendali esistenti nell'impresa (il cosiddetto modello AS-IS) e lo stato di cose ideale per cosa lottare (modello TO-BE). La metodologia IDEF0 prescrive la costruzione di un sistema gerarchico di diagrammi, i.e. singole descrizioni di frammenti di sistema. Innanzitutto, viene eseguita una descrizione del sistema nel suo insieme e la sua interazione con il mondo esterno (diagramma di contesto), dopo di che viene eseguita una scomposizione funzionale il sistema è suddiviso in sottosistemi e ogni sistema è descritto separatamente (diagrammi di scomposizione). Quindi ogni sottosistema viene suddiviso in sottosistemi più piccoli e così via per ottenere il livello di dettaglio desiderato.

Se nel processo di modellazione è necessario illuminare gli aspetti specifici della tecnologia aziendale, BPwin consente di passare a qualsiasi ramo del modello in notazione DFD o IDEF3. I diagrammi DFD (Data Flow Diagramming) possono integrare ciò che si riflette già nel modello IDEF3, poiché descrivono i flussi di dati, consentendo di tracciare il modo in cui le informazioni vengono scambiate tra le funzioni aziendali all'interno del sistema. Allo stesso tempo, i diagrammi DFD ignorano le interazioni tra le funzioni aziendali.

In termini di sequenza del lavoro svolto. E un'immagine ancora più accurata può essere ottenuta integrando il modello con diagrammi IDEF3. Questo metodo richiama l'attenzione sull'ordine in cui vengono eseguiti gli eventi. Elementi di logica sono inclusi in IDEF3, che consente di modellare e analizzare scenari alternativi per lo sviluppo di un processo aziendale.

Per considerare i processi aziendali nel magazzino di un negozio, è necessario utilizzare solo due metodologie IDEF0 e DFD. Il processo di modellazione di un sistema in IDEF0 inizia con la definizione del contesto, ad es. il livello più astratto di descrizione del sistema o dei processi aziendali in generale.

Modello IDEF0 ... Per studiare i processi aziendali "Formazione di un ordine fornitore", "Ricevimento merci", "Uscita merci", si consideri i diagrammi presentati sotto forma di diagramma IDEF0. Il sistema IDEF0 si presenta come una raccolta di attività o funzioni interagenti.

La metodologia IDEF0 si basa su quattro concetti principali.

Il primo è il concetto blocco funzionale (Scatola delle attività) ... Un blocco funzionale è rappresentato graficamente come un rettangolo e personifica una funzione specifica nell'ambito del sistema in esame

Ciascuno dei quattro lati di un blocco funzionale ha il suo significato specifico (ruolo), mentre:

Il lato superiore è Control;

Il lato sinistro è impostato su "Input";

Il lato destro è impostato su Output;

Lo svantaggio è "Meccanismo".

La seconda "balena" della metodologia IDEF0 è il concetto di un arco di interfaccia (Arrow). La visualizzazione grafica dell'arco dell'interfaccia è una freccia unidirezionale. Ogni arco dell'interfaccia deve avere il proprio nome (Arrow Label). Con l'aiuto degli archi di interfaccia, vengono visualizzati vari oggetti, che in un modo o nell'altro determinano i processi che si svolgono nel sistema. In questo caso le frecce, a seconda di quale faccia del rettangolo di lavoro entrano o da quale faccia escono, si dividono in:

Frecce di input (incluse nella parte sinistra del blocco funzionale): rappresentano dati o oggetti che vengono modificati durante l'esecuzione del lavoro;

Frecce di controllo (incluse nella faccia superiore del blocco funzionale) - raffigurano le regole e le restrizioni a causa delle quali viene eseguito il lavoro;

Frecce di uscita (uscita dal lato destro del blocco funzionale) - rappresentano dati o oggetti che appaiono come risultato del lavoro;

Le frecce del meccanismo (incluse nel bordo inferiore del blocco funzionale) - rappresentano le risorse (ad esempio, attrezzature, risorse umane).

Il terzo concetto di base dello standard IDEF0 è la decomposizione. Il principio di scomposizione viene utilizzato quando si scompone un processo complesso nelle sue funzioni costitutive.

La scomposizione consente di rappresentare in modo graduale e strutturato il modello del sistema sotto forma di una struttura gerarchica di schemi individuali, che lo rende meno sovraccarico e facilmente digeribile.

L'ultimo dei concetti IDEF0 è il glossario. Per ciascuno degli elementi IDEF0: diagrammi, blocchi funzione, archi di interfaccia standard esistente implica la creazione e il mantenimento di un insieme di definizioni, parole chiave, narrazioni, ecc. rilevanti che caratterizzano l'oggetto visualizzato dall'elemento dato. Questo set è chiamato glossario ed è una descrizione dell'essenza di questo elemento.

Considera i diagrammi dei processi aziendali che si verificano nel magazzino del negozio OJSC DMM, "Cleonelly":

Per la visibilità generale del sistema, è necessario costruire il contesto "Attività di magazzino dell'impresa" (vedi Figura 1.1).

Figura 1.1 - Diagramma "Attività del magazzino aziendale"

Dopo che il contesto è stato stabilito, viene eseguita la decomposizione, ad es. costruire i seguenti diagrammi nella gerarchia.

Ogni diagramma successivo è di più descrizione dettagliata una delle opere nel diagramma sopra. Un esempio di scomposizione del lavoro contestuale è mostrato nella Figura 1.2. Pertanto, l'intero sistema è suddiviso in sottosistemi al livello di dettaglio desiderato, questo sistema è diviso in tre livelli.

Figura 1.2 - Diagrammi di decomposizione di primo livello


Figura 1.3 - Diagramma "Registrazione delle merci"

Figura 1.4 - Diagramma "Emissione merce"


Figura 1.5 - Diagramma "Inserimento merce"

DFD. Questa metodologia si basa sulla costruzione di un modello dell'IS analizzato - proiettato o effettivamente esistente. In accordo con la metodologia, il modello di sistema è definito come una gerarchia di diagrammi di flusso di dati (DFD), che descrive il processo asincrono di trasformazione delle informazioni dal suo input nel sistema al suo output per l'utente. I diagrammi DFD vengono solitamente creati per visualizzare il lavoro corrente del sistema di flusso di lavoro di un'organizzazione. Molto spesso, i diagrammi DFD vengono utilizzati per completare il modello di processo aziendale implementato in IDEF0.

I componenti principali di un diagramma di flusso di dati sono:

Entità esterne (rappresentate graficamente come un quadrato): denotano un oggetto materiale o un individuo che è una fonte o un ricevitore di informazioni. Ad esempio: clienti, personale, fornitori, clienti, magazzino;

Sistemi / sottosistemi (graficamente appare come un rettangolo con angoli arrotondati) - funziona denotando funzioni o processi che elaborano e modificano le informazioni;

Gli archivi di dati sono un dispositivo astratto per archiviare informazioni che possono essere inserite in un'unità in qualsiasi momento e dopo un po 'possono essere recuperate, e ci può essere qualsiasi modo per posizionarle e recuperarle. In generale, il data store è un prototipo del futuro database e la descrizione dei dati in esso memorizzati dovrebbe essere collegata al modello informativo;

Flussi di dati: definisce le informazioni trasmesse tramite una connessione dalla sorgente al ricevitore. Il flusso di dati nel diagramma è rappresentato da una linea che termina con una freccia che indica la direzione del flusso.

Considera il diagramma del flusso di dati del problema (DFD) Figura 1.6. Questo diagramma mostra il movimento dei documenti quando una "richiesta di prodotto" arriva a un'organizzazione.

Figura 1.6 - Diagramma DFD "Uscita merci"

Considerare il seguente diagramma di flusso dei dati "Liquidazione del prodotto" (vedere la figura 1.7). Mostra il processo di esecuzione del lavoro e movimento dei documenti durante la "uscita merci".

Figura 1.7 - Grafico DFD "Liquidazione delle merci"

Nei diagrammi di flusso di dati, tutti i simboli utilizzati si sommano a un quadro generale, che dà un'idea chiara di quali dati vengono utilizzati e quali funzioni vengono eseguite dal sistema di flusso di lavoro. Allo stesso tempo, risulta spesso che i flussi di informazioni esistenti che sono importanti per le attività dell'azienda non sono implementati in modo affidabile e devono essere riorganizzati. *******

La struttura organizzativa di un'impresa che vende prodotti in spugna è considerata sull'esempio di OJSC Donetsk Manufactura M nel negozio Cleonelly:

Nella direzione dello sviluppo di sistemi di controllo e contabilità dei materiali, possono risolvere con successo i problemi:

1. Questo è il controllo sulle merci fornite e immagazzinate.

2. Informazioni su fornitori e consumatori

3. Contiene inoltre informazioni, informazioni e operazioni sul prodotto

4. Contiene un registro del rapporto merci rilasciate

5. Contiene un elenco di prodotti

6. Automazione delle funzioni di magazzino (ricevimento, spesa, storno, prenotazione merci)

7. Registrazione e archiviazione di fatture per beni e servizi acquistati e venduti, nonché fatturazione per pagamento anticipato, pagamento differito e consegna di merci

8. Creazione di fatture e contabilità delle merci emesse

9. Esecuzione di un inventario dei magazzini con la creazione di una dichiarazione di confronto, un atto di scarsità e surplus

10. Creazione di set di merci

Come indicato, il principale campo di attività di questa impresa è la vendita di prodotti di cotone. Il processo di progettazione comprende molte fasi elaborate con cura dalle strutture di gestione delle imprese di progettazione nel corso della vita questa impresa... Questo processo non può essere modificato contemporaneamente, poiché coinvolge molti reparti dell'azienda stessa, subappaltatori esterni e clienti dell'impresa di progetto. Pertanto, le imprese diffidano dell'implementazione di sistemi informativi relativi alla progettazione e ai processi di gestione dello sviluppo. Di norma, le imprese russe utilizzano i propri sviluppi in quest'area.

1.3 Requisiti di raccolta

Durante la progettazione di un sistema informativo (SI) per la "Stazione di lavoro del negozio all'ingrosso", è stato necessario raccogliere requisiti che aiutassero a creare un'interfaccia in modo tale che l'utente finale (dipendente del negozio) si sentisse a proprio agio nel lavorare con l'IS sviluppato.

Lo sviluppo dei requisiti è il processo che include le attività richieste per creare e approvare un documento di specifica dei requisiti di sistema.

Per implementare il processo di automazione della contabilità e del controllo dei materiali, è necessario che il sistema informativo possa soddisfare i seguenti requisiti funzionali:

¾ documentare i risultati.

¾ Sistema informativo deve essere implementato come IDE Visual Fox Pro.

Il programma funziona nel sistema operativo Windows 2000 / NT / XP.

Ci sono quattro fasi principali nel processo di sviluppo dei requisiti (Figura 1.8):

Analisi della fattibilità tecnica della realizzazione di un sistema;

Formazione e analisi dei requisiti;

Specifica dei requisiti e creazione della documentazione pertinente;

Attestazione dei requisiti.


La raccolta dei requisiti è una fase importante nella progettazione del software, poiché è qui che tutti i requisiti del cliente devono essere formulati correttamente e correttamente.

1.4 Specifica dei requisiti

La determinazione dei requisiti corretti è probabilmente il passaggio più critico in un progetto software. È molto importante che il formato del progetto corrisponda ai requisiti per il software assemblato dal team di sviluppo, altrimenti questi requisiti non possono essere supportati e presentati nel prodotto software. La specifica dei requisiti software (SRS) è la chiave per l'intero ciclo di vita dello sviluppo del software. Non è solo un documento derivato che definisce le specifiche di un progetto software, ma anche il documento principale utilizzato allo scopo di condurre test di qualificazione e accettazione. L'attestazione è una valutazione della qualità del lavoro dei project manager. Determina il grado di conformità di un prodotto software ai requisiti stabiliti. La specifica SRS funge da meccanismo per la registrazione dei requisiti di sistema utilizzati come criteri per l'attestazione.

Sulla base dell'SRS, viene raggiunto un accordo tra clienti e produttori del prodotto software. La specifica SRS descrive completamente le funzioni che il prodotto software sviluppato deve eseguire. Ciò consente ai potenziali utenti di determinare il grado in cui il prodotto soddisfa le loro esigenze, nonché i modi per modificare il prodotto in modo che sia più utile per risolvere i loro problemi.

Riduce i tempi di sviluppo. Vari gruppi all'interno dell'organizzazione del cliente sono coinvolti nella preparazione della specifica SRS. Esaminano a fondo tutti i requisiti prima che inizi lo sviluppo effettivo del progetto. Ciò riduce la probabilità di riprogettazione, codifica e test successivi.

Un attento esame dei requisiti nella specifica SRS può rivelare sviste, incomprensioni e incoerenze all'inizio del ciclo di sviluppo, quando i problemi sono molto più facili da risolvere che successivamente.

La specifica SRS diventa la base per la stima e la pianificazione dei costi. La descrizione del prodotto è la base reale per la stima del costo di un progetto. In un ambiente in cui esiste il concetto di proposta formale, l'SRS viene utilizzato per convalidare la stima di una proposta o di un prezzo.

Con specifiche ben scritte, gli SRS a livello di organizzazione possono sviluppare piani di certificazione e audit molto più produttivi. Nell'ambito del contratto di sviluppo, l'SRS fornisce un punto di riferimento per la valutazione della conformità alle specifiche.

La specifica SRS semplifica il trasferimento del prodotto software a nuovi utenti, nonché l'installazione su altri computer. Pertanto, diventa più facile per i clienti trasferire il prodotto software ad altri reparti dell'organizzazione e per gli sviluppatori trasferirlo ad altri clienti.

La specifica SRS serve come base per la modernizzazione. Questo documento tratta il prodotto stesso, non il processo di sviluppo del progetto, quindi può essere utilizzato per espandere il prodotto finito.

Dopo aver completato il processo di definizione e specifica dei requisiti, è necessario eseguire la convalida dei requisiti.

La specifica dei requisiti per il progetto software dovrebbe essere presentata nell'Appendice A.

1.5 Attestazione dei requisiti

La validazione deve dimostrare che i requisiti definiscono realmente il sistema che il cliente vuole avere. La convalida dei requisiti è importante perché un errore nella specifica dei requisiti può portare a rilavorazioni del sistema e costi elevati se scoperto durante il processo di sviluppo del sistema o dopo averlo messo in funzione.

Durante il processo di attestazione dei requisiti, devono essere eseguiti vari tipi di controlli della documentazione dei requisiti:

1. Verifica della correttezza dei requisiti.

2. Controllo della coerenza.

3. Verificare la completezza.

4. Verifica di fattibilità.

Esistono numerosi metodi di attestazione dei requisiti che possono essere utilizzati insieme o ciascuno separatamente:

1. Revisione dei requisiti.

2. Prototipazione.

3. Generazione di script di test.

4. Analisi automatizzata della coerenza.

La prototipazione è la più visibile per il cliente del sistema.

Prima di iniziare la prototipazione, è possibile creare un diagramma di flusso dell'interfaccia utente. Questo diagramma viene utilizzato per studiare le relazioni tra gli elementi principali dell'interfaccia utente.

Il passaggio successivo nella convalida dei requisiti è la prototipazione diretta.

Un prototipo di software è un'implementazione parziale o possibile di un nuovo prodotto proposto. I prototipi consentono di svolgere tre compiti principali: chiarire e completare il processo di formulazione dei requisiti, esplorare soluzioni alternative e creare il prodotto finale.

Il prototipo del menu principale di questo modulo è mostrato nella Figura 1.9.

1.6 Scegliere una metodologia di progettazione del sistema informativo

L'essenza dell'approccio strutturale allo sviluppo di una SI risiede nella sua scomposizione (partizionamento) in funzioni automatizzate: il sistema è suddiviso in sottosistemi funzionali, che a loro volta sono suddivisi in sottofunzioni, suddivisi in compiti e così via. Il processo di partizionamento continua fino a procedure specifiche. Allo stesso tempo, il sistema automatizzato mantiene una visione olistica in cui tutti i componenti costitutivi sono interconnessi.

Tutte le metodologie di approccio strutturale più comuni si basano su una serie di principi generali. I seguenti principi vengono utilizzati come due principi di base:

Dividi e conquista - il principio di risolvere problemi complessi suddividendoli in molti problemi più piccoli e indipendenti che sono facili da capire e risolvere;

Il principio di ordinamento gerarchico è il principio di organizzare le parti costitutive di un problema in strutture ad albero gerarchiche con l'aggiunta di nuovi dettagli ad ogni livello.

L'analisi strutturale utilizza principalmente due gruppi di strumenti per illustrare le funzioni svolte dal sistema e le relazioni tra i dati. Ogni gruppo di fondi corrisponde a determinati tipi di modelli (diagrammi), i più comuni, tra i quali sono i seguenti:

Modelli SADT (Structured Analysis and Design Technique) e relativi diagrammi funzionali;

Diagrammi di flusso dati DFD (Data Flow Diagrams);

Diagrammi ERD (Entity-Relationship Diagrams) entità-relazione.

Nella fase di progettazione dell'IS, i modelli vengono ampliati, perfezionati e integrati con schemi che riflettono la struttura del software: architettura software, schemi strutturali programmi e diagrammi di schermate.

I modelli elencati insieme forniscono una descrizione completa dell'IP, indipendentemente dal fatto che sia esistente o sviluppato di recente. La composizione degli schemi in ogni caso specifico dipende dalla completezza richiesta della descrizione del sistema.

2 PROGETTAZIONE DEL SISTEMA INFORMATIVO

2.1 Progettazione architettonica

Quando si crea un qualsiasi sistema informativo complesso, la sua architettura è un aspetto critico, dove rappresenta una visione concettuale della struttura dei futuri processi funzionali e tecnologie a livello di sistema e in interconnessione. In genere, i sistemi informativi complessi delle organizzazioni sono progettati come una composizione di componenti interagenti di alto livello, che possono essere essi stessi sistemi. L'architettura del sistema informativo di un'organizzazione semplifica la comprensione del sistema definendone la funzionalità e la struttura in modo da rivelare le decisioni di progettazione e consentire all'osservatore di porre domande sul rispetto dei requisiti di progettazione, sull'allocazione delle funzionalità e sull'implementazione dei componenti.

L'architettura del sistema informativo di un'organizzazione è un modello di come la tecnologia dell'informazione supporterà gli obiettivi principali e la strategia di sviluppo di un oggetto automatizzato. Consente di pensare in modo critico e di articolare una visione di come dovrebbero essere strutturati i set integrati di sistemi di informazione per raggiungere questi obiettivi. L'architettura del sistema informativo descrive il modo in cui i sistemi informativi, le applicazioni e le persone lavorano in un'organizzazione in modo uniforme e unificato.

Pertanto, l'architettura di un sistema informativo include un insieme generalmente accettato di componenti che forniscono i "mattoni" di un sistema informativo. Questi "elementi costitutivi" e le loro caratteristiche sono definiti al livello di dettaglio appropriato per soddisfare le esigenze delle decisioni di pianificazione.

Quando si progettano i moderni sistemi informativi delle organizzazioni, la loro architettura dovrebbe essere sviluppata tenendo conto di molte parti interessate, dovrebbe essere comprensibile per gli utenti, consentire agli sviluppatori di pianificare e programmare il sistema, consentire di definire interfacce, funzioni e tecnologie chiave e consentire anche di stimare la pianificazione e il budget del progetto. Ciò richiede la responsabilità degli architetti dei moderni sistemi informativi di creare un concetto soddisfacente e funzionante del sistema nella prima fase del suo sviluppo, di mantenere l'integrità di questo concetto durante lo sviluppo e di determinare l'idoneità del sistema risultante per l'uso da parte del cliente. L'architettura del sistema informativo, d'altra parte, è il processo di descrizione delle architetture del sistema informativo in modo sufficientemente dettagliato da renderle più utili per la progettazione del sistema informativo.

Lo studio dell'esperienza estera mostra che nei paesi sviluppati, quando si sviluppa un'architettura del sistema informativo, devono essere soddisfatte le seguenti condizioni:

¾ concentrarsi sulla missione dell'organizzazione;

¾ concentrarsi sui requisiti;

¾ concentrarsi sullo sviluppo;

¾ capacità di adattamento;

¾ la necessità di flessibilità.

Il rispetto di tutte queste condizioni consente di sviluppare l'architettura del sistema informativo dell'organizzazione più perfetta ed efficiente.

Le principali architetture software attualmente in fase di implementazione sono:

¾ file-server;

¾ client-server;

¾ multi-livello.

File server ... Questa architettura di database centralizzata con accesso alla rete assume la nomina di uno dei computer della rete come server dedicato, che memorizzerà i file del database centralizzato. In base alle richieste degli utenti, i file dal file server vengono trasferiti alle stazioni di lavoro degli utenti, dove viene eseguita la maggior parte dell'elaborazione dei dati. Il server centrale svolge principalmente solo il ruolo di archiviazione dei file, non partecipando all'elaborazione dei dati stessi. Dopo il completamento del lavoro, gli utenti copiano i file con i dati elaborati sul server, da dove possono essere prelevati ed elaborati da altri utenti. Questa organizzazione della manutenzione dei dati presenta una serie di inconvenienti, ad esempio, quando più utenti accedono agli stessi dati contemporaneamente, le prestazioni lavorative diminuiscono drasticamente, poiché è necessario attendere che l'utente che lavora con i dati finisca di lavorare. In caso contrario, le modifiche apportate da alcuni utenti potrebbero essere sovrascritte da modifiche apportate da altri utenti.

Client-server ... Questo concetto si basa sull'idea che, oltre a memorizzare i file del database, il server centrale deve eseguire la maggior parte dell'elaborazione dei dati. Gli utenti accedono al server centrale utilizzando uno speciale linguaggio di query strutturato (SQL, Structured Query Language), che descrive l'elenco delle attività eseguite dal server. Le richieste dell'utente vengono ricevute dal server e in esso generano processi di elaborazione dati. In risposta, l'utente riceve un set di dati già elaborato. Non l'intero set di dati viene trasferito tra il client e il server, come nel caso della tecnologia file-server, ma solo i dati di cui il client ha bisogno. Una query utente lunga solo poche righe può generare un'elaborazione dei dati che coinvolge molte tabelle e milioni di righe. In risposta, il cliente può ricevere solo pochi numeri. La tecnologia client-server evita la trasmissione di enormi quantità di informazioni sulla rete spostando tutta l'elaborazione dei dati su un server centrale. Inoltre, l'approccio in esame consente di evitare conflitti di modifiche agli stessi dati da parte di più utenti, tipici della tecnologia file-server. La tecnologia client-server implementa la modifica coerente dei dati da parte di più client, garantendo l'integrità automatica dei dati. Questi e alcuni altri vantaggi hanno reso la tecnologia client-server molto popolare. Gli svantaggi di questa tecnologia includono requisiti di prestazioni elevate per il server centrale. Più client accedono al server e maggiore è la quantità di dati elaborati, più potente deve essere il server centrale.

Sulla base di queste considerazioni, durante la progettazione dell'architettura AWS, è stata presa come base la tecnologia client-server. I diagrammi di layout mostrano le relazioni fisiche tra i componenti software e hardware di un sistema.)

2.2 Progettazione dell'interfaccia del sistema informativo

L'interfaccia utente viene spesso intesa solo come aspetto programmi. Tuttavia, in realtà, l'utente percepisce l'intero sistema nel suo insieme attraverso di lui, il che significa che una tale comprensione di lui è troppo ristretta. In realtà, l'interfaccia utente include tutti gli aspetti del design che influenzano l'interazione tra l'utente e il sistema. Non è solo lo schermo che l'utente vede. L'interfaccia utente è composta da molti componenti, come:

una serie di attività dell'utente che risolve utilizzando il sistema;

controlli di sistema;

navigazione tra blocchi di sistema;

progettazione visiva delle schermate dei programmi.

Ecco alcuni dei vantaggi aziendali più significativi di una buona interfaccia utente:

ridurre il numero di errori degli utenti;

ridurre i costi di manutenzione del sistema;

ridurre la perdita di produttività dei dipendenti durante l'implementazione del sistema e un più rapido recupero della perdita di produttività;

migliorare il morale del personale;

ridurre i costi di modifica dell'interfaccia utente su richiesta degli utenti;

disponibilità di funzionalità di sistema per numero massimo utenti.

La base all'ingrosso AWP è sviluppata come un'applicazione utilizzando la tecnologia client-server.

2.2.1 Interfaccia utente del programma di controllo

Il modulo principale della "AWP Wholesale Base" è il modulo Luck.exe, che fornisce l'implementazione delle funzionalità principali del diagramma dei casi d'uso presentato nella Figura 1.9 della Sezione 1.4.

Quando si sviluppa un sistema informativo, uno dei compiti principali è creare l'interfaccia più semplice e non caricata. È l'interfaccia del prodotto software che aiuta gli utenti a "comunicare" con il sistema informativo, fungendo da dialogo tra l'utente e il sistema.

Interfaccia del programma, parte amministrativa:

1. forma di partenza del programma. Questo modulo viene lanciato all'avvio del prodotto software, costituendo così l'inizio di un dialogo dell'utente con il sistema (Figura 2.3);

2. modulo di amministrazione. In questa forma si effettua la gestione completa del sistema informativo, i.e. aggiunta, eliminazione, modifica dei dati nel database, nonché, se necessario, visualizzazione e stampa di report (Figura 2.4);

3. Modulo "Clienti", grazie a questo modulo, è possibile visualizzare le informazioni complete sui clienti dell'azienda (Figura 2.7);

4. Modulo "Fornitori", grazie a questo modulo, è possibile visualizzare le informazioni complete sui clienti dell'impresa (Figura 2.8).

Interfaccia utente del programma:

Nella finestra per l'arrivo della merce è in corso la registrazione della merce Quando si sceglie questa scheda del modulo, l'utente deve prima

Nel menu delle spese sono presenti le operazioni svolte dall'addetto del magazzino per lo svincolo e la vendita della merce.

Nei saldi del menu vengono conteggiate le merci, i nomi degli articoli immagazzinati nel magazzino.

Nel menu cassiere, le informazioni sugli ordini di accredito e sugli ordini di flussi di cassa in uscita sono memorizzate qui. (Screenshot)

2.2.2 Interfacce utente dei componenti di controllo

Fig 2.0 Menu principale del programma

La finestra principale del programma è mostrata in Fig. 1.9. Come puoi vedere dalla figura, oltre al menu principale, già descritto sopra, conterrà anche un pannello di controllo (pulsanti "Entrate", "Consumi", "Accesso", "Saldi", "Cassa", "Rivalutazione", "Analitica", " Directory "," Servizio "e" Esci dal programma ").

Figura 2.1 Finestra del menu di ricevimento o ricevimento a magazzino.


Figura 2.2 Finestra del menu dei consumi

Figura 2.2 Finestra del menu che regola i diritti di accesso al programma.

Figura 2.3 Finestra del menu del resto della merce.

Figura 2.4 Finestra del menu del registratore di cassa.


Figura 2.4 Finestra del menu Rivalutazione.

2.3 Progettazione del database

ERwin 4.0 di Computer Associates Int è stato utilizzato per progettare il database.

ERwin è uno strumento di progettazione di database potente e facile da usare che ha ottenuto un'ampia accettazione e popolarità. Fornisce la massima produttività nello sviluppo e nella manutenzione di applicazioni basate su database. Durante l'intero processo - dalla modellazione logica dei requisiti informativi e delle regole aziendali che definiscono il database, all'ottimizzazione del modello fisico secondo le caratteristiche specificate - ERwin consente di visualizzare visivamente la struttura e gli elementi di base del database.

ERwin non è solo il miglior strumento per la progettazione di database, ma anche uno strumento per il loro creazione veloce... ERwin ottimizza il modello in base alle caratteristiche fisiche del database di destinazione. A differenza di altri strumenti, ERwin mantiene automaticamente la coerenza dello schema logico e fisico e traduce costrutti logici come le relazioni molti-a-molti in implementazioni fisiche. Facilita la progettazione del database. Per fare ciò, è sufficiente creare un modello E-R grafico (relazione-oggetto) che soddisfi tutti i requisiti di dati e inserire regole di business per creare un modello logico che visualizza tutti gli elementi, attributi, relazioni e raggruppamenti. Erwin ha due livelli di presentazione del modello: logico e fisico. Il livello logico è una visione astratta dei dati, su di esso i dati sono presentati come appaiono nel mondo reale e possono essere chiamati come vengono chiamati nel mondo reale, ad esempio " Cliente abituale"," Reparto "o" Cognome del dipendente ". Gli oggetti del modello rappresentati a livello logico sono chiamati entità e attributi. Il livello logico del modello dati è universale e non ha nulla a che fare con un'implementazione specifica del DBMS. Esistono tre sottolivelli del livello logico del modello di dati, che differiscono per la profondità di presentazione delle informazioni sui dati:

Diagramma delle relazioni tra entità (ERD);

Modello basato su chiave (KB);

Modello completamente attribuito (FA).

Diagramma delle entità: la relazione include entità e relazioni che riflettono le regole aziendali principali del dominio. Tale diagramma non è troppo dettagliato, include le entità principali e le relazioni tra loro che soddisfano i requisiti di base. Diagramma di entità: una relazione può includere relazioni molti a molti e non includere descrizioni chiave. In genere, ERD viene utilizzato per presentazioni e discussioni di strutture dati con esperti di dominio. Un modello di dati basato su chiavi è una visualizzazione più dettagliata dei dati. Include una descrizione di tutte le entità e delle chiavi primarie e ha lo scopo di rappresentare la struttura dei dati e le chiavi che corrispondono all'area tematica.

Un modello logico è la rappresentazione più dettagliata di una struttura dati: rappresenta i dati nella terza forma normale e include tutte le entità, gli attributi e le relazioni (vedi Appendice B).

Modello fisico dei dati al contrario, dipende dallo specifico DBMS, essendo di fatto una visualizzazione del catalogo di sistema. Il livello fisico del modello contiene informazioni su tutti gli oggetti nel database. Poiché non esistono standard per gli oggetti di database (ad esempio, non esiste uno standard per i tipi di dati), il livello fisico del modello dipende dall'implementazione specifica del DBMS. Di conseguenza, più livelli fisici differenti di modelli differenti possono corrispondere allo stesso livello logico di un modello. Se a livello logico del modello non ha molta importanza quale tipo di dati specifico dell'attributo (sebbene siano supportati tipi di dati astratti), a livello fisico del modello è importante descrivere tutte le informazioni su oggetti fisici specifici: tabelle, colonne, indici, procedure, ecc. ... La suddivisione del modello di dati in livelli logici e fisici consente di risolvere diversi problemi importanti.

Il modello fisico dei dati è presentato nell'Appendice B.

2.4 Motivazioni per la scelta di una piattaforma per la creazione di un sistema informativo

Visual FoxPro è un ambiente di sviluppo visivo per sistemi di gestione di database relazionali attualmente disponibile da Microsoft. L'ultima versione è la 9.0. Utilizza il linguaggio di programmazione FoxPro. La versione di sistema 7.0 può essere eseguita su kernel Windows 9x e NT, versioni 8.0 e 9.0 - solo su Windows XP, 2000, 2003.

FoxPro (Fox-pro?) È uno dei dialetti del linguaggio di programmazione xBase. Viene utilizzato principalmente per lo sviluppo di DBMS relazionali, sebbene sia possibile utilizzarlo per lo sviluppo di altre classi di programmi Come notato sopra, il linguaggio VFP è un linguaggio xBase fortemente ampliato ed esteso. In Visual FoxPro, un linguaggio di programmazione, ovvero la costruzione di base di un linguaggio è il concetto di una classe. La versione originale di xBase è il linguaggio strutturale più puro, con un concetto di base di procedure e funzioni. Pertanto, il linguaggio di programmazione moderno Visual FoxPro consente di combinare sia la programmazione "antiquata" descrivendo una massa di procedure e nello stile OOP, creando una gerarchia di classi complessa.

Ho scelto questo linguaggio di programmazione perché contiene una serie dei seguenti vantaggi:

¾ Un noto formato di tabella di database che consente di organizzare facilmente lo scambio di informazioni con altre applicazioni Microsoft Windows.

Organizzazione moderna di database relazionali, che consente di archiviare informazioni su tabelle di database, loro proprietà, indici e relazioni, impostare condizioni di integrità referenziale, creare visualizzazioni locali e remote, connessioni a server, stored procedure eseguite quando si verificano più di 50 diversi tipi di eventi (VFP 7.0-9.0).

Alta velocità di lavoro con basi grandi dati.

Elevata visibilità del lavoro con i database: la finestra multifunzionale della sessione Dati consente di vedere l'elenco delle tabelle del database aperte, le loro relazioni, i filtri, l'ordine degli indici, le modalità di buffering, passare alle modalità di modifica della struttura, lavorare con le informazioni della tabella, ecc.

Alta velocità di sviluppo delle applicazioni utilizzando procedure guidate, Designer, Builders, modalità suggerimenti IntelliSense durante la scrittura di programmi, il debug e il test dei programmi.

La capacità di sviluppare applicazioni basate sulla tecnologia "client-server" con dati localizzati su database server Oracle e Microsoft SQL Server e altre applicazioni Microsoft Windows che utilizzano ODBC e OLE

Il sistema VFP è destinato all'uso da parte di programmatori professionisti, quindi non ha senso russificarne il menu e la lingua: per qualsiasi programmatore, la sintassi inglese di un linguaggio algoritmico è più familiare del russo.

2.5 Progettazione di moduli

Soffermiamoci più in dettaglio sulla progettazione di uno dei moduli del programma e consideriamo, usando il suo esempio, i passaggi necessari per creare un progetto.

Ad esempio, prenderò in considerazione la progettazione di un modulo che implementa il caso d'uso "Emette una domanda di ammissione".

Innanzitutto, descriviamo il flusso di eventi che si verificano in questo caso d'uso.

Una condizione preliminare per un caso d'uso è la ricezione di una richiesta da un client.

5. Il caso d'uso inizia quando il cliente invia la domanda.

6. Il manager apre il modulo Entrate.

7. Il manager imposta la data della domanda.

8. Il manager inserisce il nome del prodotto.

9. Il gestore inserisce la quantità della merce ricevuta.

10. Il manager inserisce l'importo della domanda.

11. Il manager chiude il modulo.

12. Il caso d'uso termina.

La postcondizione al caso d'uso è la registrazione di un'applicazione nel sistema e la comparsa di un nuovo cliente nel journal del modulo principale.

Considera un diagramma di sequenza questa opzione uso. Come puoi vedere da questo diagramma, il gestore, aprendo il modulo di arrivo, fa eseguire diverse azioni - automaticamente (dal punto di vista del gestore) viene compilata la data della domanda. Quando si inserisce un'applicazione, l'elenco dei clienti viene compilato dalla base con le informazioni primarie. Successivamente, il manager inserisce tutti i dati necessari e fa clic sul pulsante "Accetta". In questo caso, vengono eseguite le seguenti azioni. Tutti i dati vengono passati alla stored procedure.

3 Implementazione e validazione del sistema informativo

3.1 Implementazione dell'applicazione

L'implementazione dell'applicazione, nella sua essenza, è una delle fasi laboriose per lo sviluppatore del sistema informativo, perché i requisiti che il cliente propone devono essere integrati in modo chiaro e corretto nel sistema. Finora non esistono prodotti software di questo tipo in grado di "adattarsi" alle esigenze del cosiddetto cliente e fornire un certo insieme di funzioni per l'implementazione del sistema che soddisfino tali requisiti. Pertanto, ogni sviluppatore deve scegliere l'ambiente ottimale per lo sviluppo del sistema, ma va notato che quando si implementa un'applicazione, non si può fare a meno di scrivere il codice del programma. È durante la scrittura del codice del programma che verranno implementate alcune funzioni che il sistema deve eseguire. A seconda dell'ambiente di implementazione del sistema selezionato, il codice del programma avrà un aspetto diverso, in un ambiente come Microsoft Visual FoxPro ci sarà un codice di programma, in Visual Basic un altro, ecc.

In questo caso, l'applicazione è stata implementata in Microsoft Visual FoxPro.

Di seguito verranno descritte le principali funzioni del sistema:

1. La forma iniziale del sistema. Questo modulo è un modulo pulsante e, di conseguenza, ogni pulsante svolge la sua funzione. Il pulsante di registrazione dell'amministratore è mostrato nella Figura 3.1 Questo pulsante eseguirà la funzione che apre il pannello dell'amministratore se l'utente dispone di tali diritti su questo sistema.

2. Arrivo del pulsante del menu. Questo pulsante consente di tenere traccia delle merci in arrivo al magazzino del negozio Figura 3.2.

3. Nel pulsante del menù viene tenuta traccia della spesa della merce rilasciata dal magazzino Figura 3.3.

4. Nel pulsante del menu di accesso sono regolati i diritti di utilizzo di questo programma Figura 3.4.

5. Il pulsante menu rimane memorizza le informazioni sui materiali immagazzinati nel magazzino del negozio Figura 3.5.

6. Il pulsante del menu della cassa memorizza le informazioni sugli ordini di cassa in entrata e sugli ordini di cassa in uscita Figura 3.6.

7. Nella rivalutazione del pulsante di menu, il prezzo cambia per nuovo prezzo merci fig. 3.7.

Figura 3.1 - Schermata di avvio del sistema


Figura 3.2 - Forma di contabilizzazione delle entrate merci a magazzino.

Figura 3.3– Forma di contabilizzazione delle merci rilasciate.

Figura 3.4– Modulo che regola i diritti di accesso al programma.


Figura 3.5– Forma dei resti della merce nel magazzino.

Figura 3.5 - Modulo sugli incassi e gli incassi.


Figura 3.6 - Forma delle operazioni sulle merci.

Test dell'applicazione

Il test è il processo di esecuzione di un programma per rilevare gli errori. Il test fornisce:

Rilevamento degli errori;

Dimostrazione della conformità delle funzioni del programma con il suo scopo;

Dimostrazione dell'attuazione dei requisiti per le caratteristiche del programma;

Visualizzazione dell'affidabilità come indicatore della qualità del programma.

La Figura 3.2 mostra i flussi di informazioni del processo di test.


Ci sono tre flussi all'ingresso del processo di test:

Testo del programma;

Dati iniziali per l'avvio del programma;

Risultati aspettati.

I test vengono eseguiti e tutti i risultati ottenuti vengono valutati. Ciò significa che i risultati effettivi del test vengono confrontati con i risultati attesi. Quando viene rilevata una mancata corrispondenza, viene registrato un errore e inizia il debug.

Dopo aver raccolto e valutato i risultati dei test, inizia la visualizzazione della qualità e affidabilità del software. Se si riscontrano regolarmente errori gravi che richiedono modifiche alla progettazione, la qualità e l'affidabilità del software sono sospette e viene dichiarata la necessità di rafforzare i test.

I risultati accumulati durante i test possono essere valutati in modo più formale. Per questo, vengono utilizzati modelli di affidabilità del software che prevedono l'affidabilità in base a dati reali sul tasso di errore.

Esistono 2 principi per il test del software:

Test funzionali (test black box);

Test strutturali (test white box).

Quando si prova il metodo "scatola bianca", la struttura interna del programma è nota. L'oggetto del test qui non è l'esterno, ma il comportamento interno del programma. Vengono verificate la correttezza della costruzione di tutti gli elementi del programma e la correttezza della loro interazione reciproca.

Il test black box (test funzionale) consente di ottenere combinazioni di dati di input che forniscono un controllo completo di tutti i requisiti funzionali per il programma //. Un prodotto software è qui considerato come una "scatola nera" il cui comportamento può essere determinato solo esaminando i suoi input e gli output corrispondenti.

Il principio della "scatola nera" non è un'alternativa al principio della "scatola bianca". Piuttosto, è un approccio complementare che rileva una diversa classe di errori.

Il test della scatola nera cerca le seguenti categorie di errore:

Caratteristiche errate o mancanti;

Errori di interfaccia;

Errori nelle strutture dati esterne o nell'accesso a un database esterno;

Errori caratteristici (capacità di memoria richiesta, ecc.);

Errori di inizializzazione e completamento.

A differenza del test della scatola bianca, che viene eseguito all'inizio del processo di test, il test della scatola nera viene utilizzato nelle fasi successive del test. Durante il test della scatola nera, la struttura di controllo del programma viene trascurata. Qui il focus è sull'area delle informazioni della definizione del sistema software. Il test durante questa fase si concentra sull'idoneità della soluzione per un ambiente di produzione live. L'obiettivo è correggere i bug, identificare la loro gravità e preparare il prodotto per il rilascio.

Nella fase di test vengono risolti due compiti principali:

Solution Testing - Vengono eseguiti i piani di test creati durante la fase di pianificazione ed estesi e testati durante la fase di sviluppo;

Operazione pilota - implementazione della soluzione in un ambiente di test e test con il coinvolgimento di futuri utenti e l'implementazione di scenari reali di utilizzo del sistema. Questa attività viene completata prima dell'inizio della fase di distribuzione.

Lo scopo della fase di test è ridurre il rischio che si verifica quando la soluzione viene messa in esercizio commerciale.

Affinché la fase di test abbia successo, è necessario un cambiamento di atteggiamento nei confronti del progetto e lo sviluppatore passa dallo sviluppo di nuove funzionalità per garantire la corretta qualità della soluzione.

In questa fase di sviluppo del sistema informativo, dovrebbero essere effettuati i seguenti tipi di test:

Test di base - Livello basso prove tecniche... Viene eseguito dallo sviluppatore stesso durante il processo di scrittura del codice del programma. Viene applicato il metodo "scatola bianca", alto rischio di errori.

Test di usabilità: test di alto livello eseguiti dal tester e dai futuri utenti del prodotto. Viene applicato il metodo "scatola nera".

Alpha e Beta Testing - In termini di MSF, il codice alpha è fondamentalmente tutto il codice sorgente che è stato creato durante la fase di sviluppo del modello di processo MSF, e il codice beta è il codice che è stato testato durante la fase di test. Pertanto, il codice alfa viene testato durante la fase di sviluppo del modello di processo MSF e il codice beta viene testato durante la fase di test.

Test di compatibilità: la soluzione in fase di sviluppo richiede l'integrazione e l'interoperabilità con i sistemi e le soluzioni software esistenti. Questa forma di test si concentra sulla verifica dell'integrabilità e della capacità della soluzione sviluppata di interagire con i sistemi esistenti. In questo caso particolare, verrà verificato il corretto funzionamento dell'applicazione sull'attrezzatura dell'utente e sul software utilizzato dall'utente.

Test delle prestazioni: incentrato sulla verifica della conformità dell'applicazione ai requisiti di prestazione e al livello di comfort in termini di velocità.

Documentazione e test del sistema di guida: vengono testati tutti i documenti di supporto sviluppati e i sistemi di guida.

L'operazione pilota sta testando una soluzione in un ambiente industriale. L'obiettivo principale dell'operazione pilota è dimostrare che la soluzione è in grado di funzionare in modo stabile in condizioni industriali e soddisfa i requisiti aziendali. Durante l'operazione pilota, la soluzione viene testata in condizioni reali. Il funzionamento pilota consente agli utenti di fornire feedback sulle prestazioni del prodotto. Guidato da questa opinione, lo sviluppatore elimina tutti i possibili problemi o crea un piano d'azione in caso di circostanze impreviste. Infine, l'operazione pilota consente di decidere se avviare una distribuzione completa o rimandare fino alla risoluzione dei problemi che potrebbero interrompere la distribuzione.

Il piano del processo operativo pilota per il sistema informativo sviluppato è mostrato nella Tabella 3.2.

Tabella 3.2 - Piano operativo pilota

atto

Descrizione

1. Scelta dei criteri per il successo

Lo sviluppatore e i partecipanti al test definiscono i criteri di successo e concordano su di essi

2. Scelta degli utenti e luogo di installazione

Si sta formando un team di partecipanti al test pilota da parte di utenti e sviluppatori. Viene determinata la posizione della distribuzione del processo pilota.

3. Preparazione degli utenti e dei siti di installazione

Formazione degli utenti - partecipanti alla sperimentazione Il sito di installazione è in preparazione.

4. Distribuzione di una versione di sviluppo

Una versione sperimentale è installata e inclusa nel lavoro.

5. Supporto e monitoraggio della versione di sviluppo

Monitorare il lavoro degli utenti e del sistema, fornire assistenza durante il funzionamento, raccogliere informazioni sul funzionamento del sistema

6. Feedback degli utenti e valutazione dei risultati

Gli utenti esprimono la loro opinione sul funzionamento del sistema, segnalano carenze ed errori.

7. Introduzione di modifiche e integrazioni

I bug vengono corretti, vengono apportate modifiche al design o al processo. I risultati corretti vengono forniti agli utenti per lavorare e valutare.

8. Decisioni di distribuzione

Se i risultati del lavoro di test pilota soddisfano gli utenti, viene presa la decisione di distribuire il sistema.

3.2 Metodologia di distribuzione dell'applicazione

In questa fase, lo sviluppatore (o il team) implementa le tecnologie e i componenti necessari per la soluzione, il progetto passa alla fase di manutenzione e supporto e il cliente infine lo approva. Dopo la distribuzione, il team valuta il progetto e interroga gli utenti per determinare la loro soddisfazione.

Obiettivi della fase di distribuzione:

¾  trasferire la soluzione in un ambiente industriale;

¾  riconoscimento da parte del cliente del completamento del progetto

L'implementazione di componenti specifici del sito consiste in diverse fasi: preparazione, installazione, formazione e approvazione formale.

I risultati della fase di implementazione del sistema sono sistemi di manutenzione e supporto, un repository di documenti in cui si trovano tutte le versioni dei documenti e del codice sviluppati durante il progetto.

Per implementare il sistema in fase di sviluppo, è stato elaborato un piano d'azione, che è mostrato nella Tabella 3.1.

Tabella 3.1 - Piano di distribuzione dell'applicazione

atto

Descrizione dell'azione

1. Backup

Prodotto backup dati dell'utente con la sua partecipazione e approvazione trasferendo le informazioni su un supporto rimovibile (CD, DVD)

2. Installazione componenti di base soluzioni

L'uso di tecnologie che assicurano il funzionamento della soluzione. In questo caso, installare il componente Visual FoxPro

3. Installazione dell'applicazione client

Trasferimento sul computer dell'utente e installazione della versione finale dell'IS e del database sviluppati

4. Formazione

Gli utenti sono addestrati a lavorare con il sistema, lo sviluppatore è convinto della correttezza e della comprensione del lavoro di IP da parte dei clienti

5. Trasferimento della knowledge base del progetto al cliente

Tutta la documentazione del progetto viene consegnata al cliente

6. Chiusura del progetto

Viene preparato un rapporto di chiusura del progetto. Il cliente firma il certificato di accettazione.

Per il normale funzionamento dell'AWP, sistema operativo Microsoft WindowsXP.

4 Gestione del progetto informativo

4.1 Scegliere un ciclo di vita di sviluppo

Uno dei concetti di base della metodologia di progettazione IS è il concetto del ciclo di vita del suo software (software del ciclo di vita). Il software Lifecycle è un processo continuo che inizia dal momento in cui viene presa la decisione sulla necessità della sua creazione e termina nel momento del suo completo ritiro dal servizio.

Il principale documento normativo che regola il ciclo di vita del software è lo standard internazionale ISO / IEC 12207 (ISO - International Organization of Standardization - International Organization for Standardization, IEC - International Electro Technical Commission - International Commission on Electrical Engineering). Definisce la struttura del ciclo di vita, contenente i processi, le azioni e le attività che devono essere eseguite durante la creazione del software.

ISO / IEC 12207 non fornisce un modello di ciclo di vita e metodi di sviluppo software specifici. Il modello del ciclo di vita può essere inteso come una struttura che determina la sequenza di esecuzione e interrelazione di processi, azioni e compiti eseguiti durante il ciclo di vita. Il modello del ciclo di vita dipende dalle specifiche dell'IS e dalle specifiche delle condizioni in cui viene creato e opera.

Oggi esistono molti modelli del ciclo di vita del software, ma i più apprezzati e diffusi sono due modelli:

Modello a spirale (vedi figura 4.1);

Modello iterativo.


Figura 4.1 - Modello a spirale del ciclo di vita del software

Per creare un sistema informativo, ad es. "Automatizzato posto di lavoro base all'ingrosso dei dipendenti di magazzino ", è stato scelto iterativo. Una caratteristica distintiva del modello iterativo è che è un metodo formale, si compone di fasi indipendenti, eseguite in modo sequenziale ed è soggetto a frequenti revisioni (Figura 4.2). L'approccio iterativo ha funzionato bene per la creazione di IS, per i quali, all'inizio dello sviluppo, tutti i requisiti possono essere formulati in modo accurato e completo in modo da dare agli sviluppatori la libertà di implementarli nel miglior modo possibile da un punto di vista tecnico.

Vantaggi del modello iterativo:

il modello è ben noto ai consumatori non di software e agli utenti finali.

Comodità e facilità d'uso, perché tutto il lavoro viene eseguito per fasi (in fasi del modello);

Stabilità dei requisiti;

Il modello è comprensibile;

Anche il personale poco formato (utente inesperto) può essere guidato dalla struttura del modello;

Il modello gestisce la complessità in modo ordinato e funziona bene per progetti ragionevolmente comprensibili;

Il modello facilita l'attuazione di uno stretto controllo della gestione del progetto;

Facilita il lavoro del project manager per pianificare e assemblare il team di sviluppo.

Figura 4.2 - Modello iterativo del ciclo di vita del software

Fasi del modello:

Nella fase di analisi, definiscono le funzioni che il sistema dovrebbe svolgere, evidenziano quelle più prioritarie che richiedono in primo luogo l'elaborazione, descrivono esigenze di informazione;

In fase di progettazione, i processi del sistema vengono considerati in modo più dettagliato. Il modello funzionale viene analizzato e, se necessario, corretto. Si stanno realizzando prototipi di sistema;

Il sistema è in fase di sviluppo in fase di implementazione;

Nella fase di implementazione, il prodotto finito viene introdotto nel sistema esistente dell'organizzazione. È in corso la formazione degli utenti;

Nella fase di manutenzione, il prodotto software viene riparato (qualsiasi aggiunta o modifica per un funzionamento più funzionale del prodotto).

La scelta di un modello del ciclo di vita dello sviluppo del software è un passo importante. Pertanto, per un progetto, la scelta di un modello di ciclo di vita di sviluppo software può essere effettuata durante l'utilizzo dei seguenti processi.

Analisi delle categorie distintive del progetto, inserite nelle tabelle.

Rispondi alle domande per ogni categoria, evidenziando le parole "sì" e "no".

Classifica per importanza le categorie o le domande relative a ciascuna categoria in relazione al progetto per il quale viene selezionato un modello accettabile.

Team di sviluppo ... In base alle possibilità, la selezione del personale per il team di sviluppo avviene ancor prima del momento in cui viene scelto il modello del ciclo di vita di sviluppo del software. Le caratteristiche di un tale team (vedere Appendice G, Tabella G.1) svolgono un ruolo importante nel processo di scelta di un modello del ciclo di vita, il che significa che il team può essere di notevole aiuto nella scelta di un modello del ciclo di vita del prodotto software, poiché è responsabile della corretta implementazione del modello del ciclo di vita sviluppato. ...

Team utenti ... Nelle fasi iniziali del progetto, è possibile ottenere un quadro completo del team di utenti (vedere Appendice E Tabella I.1) che lavorerà con il software sviluppato e la sua relazione futura con il team di sviluppo durante il progetto. Tale visione aiuta nella scelta di un modello adatto, poiché alcuni modelli richiedono una maggiore partecipazione dell'utente allo sviluppo e allo studio del progetto, poiché i requisiti possono essere leggermente modificati dall'utente durante il processo di sviluppo, lo sviluppatore deve conoscere questi cambiamenti e come rappresentare questi cambiamenti nel software.

4.2 Determinare lo scopo e l'ambito del progetto software

Il prodotto software sviluppato per la contabilità delle merci in magazzino automatizzerà il processo di ricezione, strutturazione e archiviazione dei dati sulle merci in magazzino, oltre a semplificare il processo di emissione dei rapporti.

Gli obiettivi del progetto software saranno: la creazione e l'implementazione di un sistema per la contabilità delle merci. Questo sistema destinato all'uso interno da parte del personale Cleonelly, per lo più dipendenti del magazzino dell'azienda.

Per determinare l'ambito del prodotto software, verrà descritto di seguito cosa dovrebbe o non dovrebbe essere un progetto software.

Il progetto software deve essere:

Per uso interno in un'organizzazione;

Un progetto per l'implementazione dell'accesso multiutente;

Un progetto che ha la capacità di inserire, modificare e memorizzare informazioni sul prodotto dell'azienda;

Un progetto che ha la capacità di inserire, modificare e memorizzare informazioni sugli utenti del sistema;

Un progetto che ha la capacità di inserire, modificare e memorizzare informazioni su clienti e fornitori dell'organizzazione che sono oggetto di transazioni da concludere;

Un progetto che realizzerà la formazione del reporting esterno.

4.3 Creazione della struttura dell'elenco delle opere passo passo

Per creare un prodotto o servizio unico (risultato del progetto), è necessario eseguire una determinata sequenza di lavoro. Il compito della pianificazione del progetto è quello di stimare accuratamente i tempi e il costo di questi lavori. Più accurata è la valutazione, maggiore è la qualità del piano di progetto. Per fornire una valutazione accurata, è necessario avere una buona comprensione dell'ambito del progetto, ovvero sapere esattamente quale lavoro deve essere fatto per ottenere il suo risultato. Solo dopo aver redatto l'elenco dei lavori di progettazione, viene stimata la durata di ciascuno di essi e vengono assegnate le risorse necessarie per la loro implementazione. E solo allora puoi stimare il costo e la tempistica di ciascuna attività e, come risultato dell'aggiunta, il costo totale e la durata del progetto. Questo è il motivo per cui la definizione dell'ambito di lavoro è il primo passo nella pianificazione del progetto. La determinazione dell'ambito del lavoro di progettazione inizia con la definizione delle fasi (o fasi) del progetto. Ad esempio, nel progetto di creazione di un sistema "Contabilità merce in magazzino" si possono evidenziare le seguenti fasi:

Sviluppo di requisiti software;

Progettazione di sistemi informativi;

Implementazione e certificazione del sistema informativo;

Implementazione del sistema.

Dopo aver determinato la composizione delle fasi e i loro risultati, è necessario determinare la sequenza di queste fasi l'una rispetto all'altra e le scadenze per la loro attuazione. Quindi è necessario determinare in cosa consistono le fasi, in quale sequenza vengono eseguite queste opere e in quali scadenze è necessario rispettare una volta completate.

L'elenco di lavoro passo passo (Figura 4.3) è stato progettato utilizzando un prodotto software come MS Project 2003.


Figura 4.3 - Elenco dei lavori passo passo

4.4 Stima della durata e del costo dello sviluppo del software

Stima della durata. Viene determinato dopo la costruzione di un elenco graduale di opere (Figura 4.3, paragrafo 4.3). Questa durata stimata può essere vista utilizzando il diagramma di Gantt (Appendice K).

I diagrammi sono un mezzo grafico per visualizzare le informazioni contenute in un file di progetto. Dai grafici, puoi avere un'idea visiva della sequenza delle attività, della loro durata relativa e della durata del progetto nel suo insieme.

Il diagramma di Gantt è uno dei modi più popolari per rappresentare graficamente un piano di progetto e viene utilizzato in molti programmi di gestione dei progetti.

In MS Project, il diagramma di Gantt è lo strumento di visualizzazione principale per il piano di progetto. Questo grafico è un grafico con una sequenza temporale orizzontale e un elenco verticale di attività. Inoltre, la lunghezza dei segmenti che indicano le attività è proporzionale alla durata delle attività.

Sul diagramma di Gantt è possibile visualizzare informazioni aggiuntive accanto alle barre (accanto alle attività vengono visualizzati i nomi delle risorse coinvolte e il loro caricamento al termine dell'attività).

Stima dei costi

Il progetto consiste in compiti , ovvero attività finalizzate al raggiungimento di un determinato risultato. Affinché l'attività sia completata, risorse .

Una proprietà importante delle risorse è il costo (costo) del loro utilizzo nel progetto. Esistono due tipi di costi delle risorse in MS Project: tariffa basata sul tempo e costo per utilizzo.

La tariffa basata sul tempo (Tasso) è espressa nel costo dell'utilizzo della risorsa per unità di tempo, ad esempio 100 rubli all'ora o 1000 rubli al giorno. In questo caso, il costo di partecipazione della risorsa al progetto sarà il tempo durante il quale opera nel progetto, moltiplicato per la tariffa oraria.

In questo caso è stata utilizzata la tariffa basata sul tempo (Figura 4.4) Il costo totale dell'utilizzo delle risorse può essere visto nella Figura 4.5.

Figura 4.4 - Frequenza temporale nell'utilizzo delle risorse

In questa figura, puoi vedere che lo sviluppatore del sistema riceve 50 rubli all'ora durante l'esecuzione di un progetto; un analista aziendale riceve 45 rubli all'ora, un tester 38 rubli all'ora. Le tariffe per gli straordinari non sono incluse.


Figura 4.5 - Costi totali per l'utilizzo delle risorse del progetto

4.5 Allocazione delle risorse del progetto

Un frammento della distribuzione delle risorse per il sistema "Inventory Accounting" può essere visto nella Figura 4.6


Figura 4.6 - Un frammento della distribuzione delle risorse del progetto

Per ogni lavoro svolto nel progetto, viene assegnata una risorsa che eseguirà questo lavoro... La figura mostra la quantità totale di manodopera per ciascuna risorsa e il numero specifico di ore trascorse in un giorno specifico.

4.6 Valutazione dell'efficienza economica del progetto

Il calcolo dell'efficienza economica del progetto è un passo importante. È qui che verrà calcolata l'efficienza economica del progetto. Questo calcolo mostrerà quanto sia redditizio un progetto o un progetto completamente non redditizio. Quando si calcola l'efficienza economica del progetto, sarà necessario calcolare il periodo di recupero del progetto. Il periodo di ammortamento mostrerà il periodo in cui il progetto ripagherà.

Dati in ingresso.

Utile aggiuntivo dall'attuazione del progetto (DP) \u003d 38.000 rubli. Il profitto aggiuntivo è stato previsto dagli esperti dell'azienda.

Investimento iniziale (IC) \u003d 39396,47 rubli. Gli investimenti iniziali corrispondono ai costi totali di utilizzo delle risorse del progetto (Figura 4.5, clausola 4.6)

Tasso di sconto (i) \u003d 12%.

Il periodo per il quale il progetto è concepito (n) \u003d 2 anni.

Utile aggiuntivo dall'attuazione del progetto (DP) \u003d 38.000 rubli.

Costi annuali di implementazione del progetto (Z 1) \u003d 15.000 rubli.

Costi annuali di implementazione del progetto (Z 2) \u003d 10.000 rubli.

Entrate di cassa annuali (R 1) \u003d 23.000 rubli.

Entrate di cassa annuali (R 2) \u003d 28.000 rubli.

Durante la valutazione progetti di investimento viene utilizzato il metodo di calcolo del valore attuale netto, che prevede l'attualizzazione dei flussi di cassa: tutti i proventi e costi sono portati a un punto nel tempo.

L'indicatore centrale nel metodo considerato è NPV (valore attuale netto) - il valore attuale dei flussi di cassa. Questo è un risultato finale generalizzato dell'attività di investimento in termini assoluti.

Un punto importante è la scelta del tasso di sconto, che dovrebbe riflettere il tasso di prestito medio atteso nel mercato finanziario.

Il valore attuale netto (NPV) viene calcolato utilizzando la formula 4.2

(4.2)

R k - entrate annuali di cassa per n anni.

k - il numero di anni per la durata del progetto.

IC - investimento iniziale.

i - tasso di sconto.

Secondo i calcoli di questa formula NPV \u003d RUB 3.460,67

NPV è un aumento assoluto perché stima di quanto il reddito attuale si sovrapponga ai costi attuali. Poiché NPV\u003e 0, il progetto dovrebbe essere accettato.

Il ritorno sull'investimento (ROI) viene calcolato utilizzando la formula 4.3

(4.3)

Calcolato (ROI) \u003d 108,78%

Tabella 4.1  Tabella ausiliaria per il calcolo del periodo di payback del progetto

= 1,84

Periodo di recupero dell'investimento n ok \u003d 1,84 anni (1 anno e 11 mesi)

Poiché ROI \u003d\u003e 100% (ovvero \u003d 108,78%), il progetto è considerato redditizio.

(4.4)

Pertanto, l'indice di redditività è (PI) \u003d 1,2

Gli elementi che garantiscono il funzionamento di SI per qualsiasi scopo sono elencati nella definizione. Alcuni di essi - mezzi, metodi e personale - assicurano il funzionamento del SI, mentre altri - conservazione, elaborazione ed emissione di informazioni - indicano caratteristiche funzionali, ovvero determinare da quali processi informativi è composto il funzionamento dell'IS. Pertanto, la struttura dell'IS è considerata in due modi diversi: la struttura funzionale e la struttura dell'IS come un insieme di sottosistemi di supporto.

In accordo con la definizione, gli elementi funzionali dell'IS sono i seguenti gruppi (blocchi) di processi:

    inserimento di informazioni da fonti esterne o interne;

    elaborare le informazioni di input e presentarle in una forma conveniente;

    produzione di informazioni per la presentazione ai consumatori o il trasferimento a un altro SI;

    il feedback è un'informazione elaborata dalle persone di una data organizzazione per correggere le informazioni di input.

Struttura funzionale Il sistema informativo è presentato sotto forma di uno schema a blocchi (Fig.1), in cui ogni elemento del sistema è rappresentato sotto forma di un blocco (nella Fig. - un rettangolo), ei collegamenti e le loro direzioni sono indicati da frecce.

Le singole parti (blocchi di sistema) sono chiamate sottosistemi.

In ogni caso specifico, l'insieme e le interrelazioni dei sottosistemi funzionali dipendono dall'area tematica e dalle specificità dell'impresa, la cui attività è fornita dal sistema informativo.

La struttura dell'IS può anche essere rappresentata come un complesso di sottosistemi di supporto (Fig. 2).

Fig. 1. Schema a blocchi IC funzionale generalizzato.

Tuttavia, per AIS, che differiscono per natura e tipi di elaborazione delle informazioni, il diagramma funzionale differisce in una serie di sottosistemi di elaborazione. Ad esempio, AIPS (biblioteca, museo, riferimento legale, ecc.) Produce input, sistematizzazione, archiviazione, ricerca e consegna di informazioni su richiesta dell'utente senza complesse trasformazioni dei dati. Sistemi decisivi per le informazioni: ASOD, ACS, DSS - elaborano le informazioni del database secondo un determinato algoritmo, tuttavia differiscono anche nella composizione dei sottosistemi di elaborazione delle informazioni. Un sistema CAD specializzato nell'automazione della progettazione ha nella sua struttura sottosistemi speciali: documentazione tecnica, formazione dei compiti, simulazione, calcolo, e in alcuni può esserci un sistema esperto (vedi diagramma a blocchi in Fig.2).

Fig. 2. Schema a blocchi CAD

Considera un altro tipo di struttura IS: come un complesso di sottosistemi di supporto (Fig. 3).

La struttura di un sistema informativo può essere considerata come un insieme di sottosistemi, indipendentemente dal campo di applicazione. Un sottosistema è una parte di un sistema che si distingue in base a qualche attributo. In questo caso, si parla di una caratteristica strutturale della classificazione, ei sottosistemi sono chiamati fornitura.

Pertanto, la struttura di qualsiasi sistema informativo può essere rappresentata da un insieme di sottosistemi di supporto.

Fig. 3. Struttura IS in base al tipo di sottosistemi di supporto.

Il supporto informativo, tecnico, matematico, software, organizzativo e legale viene solitamente distinto tra i sottosistemi di supporto.

Supporto informativo - una serie di set di dati informativi, un sistema unificato di classificazione e codifica delle informazioni, sistemi di documentazione unificata, schemi di flussi di informazioni che circolano in un'organizzazione, nonché una metodologia per la creazione di database. Lo scopo del sottosistema di supporto alle informazioni è la formazione e la fornitura tempestive di informazioni affidabili per prendere decisioni manageriali.

Sistemi di documentazione unificata vengono creati a livello statale, repubblicano, settoriale e regionale. L'obiettivo principale è garantire la comparabilità degli indicatori di vari ambiti della produzione sociale. Sono stati sviluppati standard in cui sono stabiliti i requisiti:

    a sistemi di documentazione unificati;

    a forme unificate di documenti di vari livelli di gestione;

    alla composizione e struttura dei dettagli e degli indicatori;

    alla procedura per l'implementazione, il mantenimento e la registrazione di forme unificate di documenti.

Nonostante l'esistenza di un sistema di documentazione unificato, un sondaggio della maggior parte delle organizzazioni rivela tutta una serie di carenze tipiche:

    volume estremamente elevato di documenti per l'elaborazione manuale;

    gli stessi indicatori sono spesso duplicati in documenti diversi;

    lavorare con un gran numero di documenti distrae gli specialisti dalla risoluzione di problemi immediati;

    ci sono indicatori che vengono creati ma non utilizzati, ecc.

L'eliminazione di queste carenze è uno dei compiti che devono affrontare la creazione di supporto informativo.

Diagrammi di flusso delle informazioni rispecchiano le rotte del movimento delle informazioni, i suoi volumi, i luoghi di origine delle informazioni primarie e l'uso delle informazioni risultanti. Analizzando la struttura di tali schemi, è possibile sviluppare misure per migliorare l'intero sistema di gestione.

La costruzione e l'analisi dettagliata dei diagrammi di flusso delle informazioni, che consentono di identificare percorsi e volumi di informazioni, duplicazione di indicatori e processi della loro elaborazione, prevede:

    eliminazione delle informazioni duplicate e inutilizzate;

    classificazione e presentazione razionale delle informazioni.

Metodologia per la creazione di database basato sui fondamenti teorici del loro design.

Concetti di base della metodologia:

    una chiara comprensione degli scopi, degli obiettivi, delle funzioni dell'intero sistema di gestione dell'organizzazione;

    identificare il movimento delle informazioni dal momento della sua origine al suo utilizzo ai vari livelli di gestione, presentate per l'analisi sotto forma di schemi di flusso di informazioni;

    miglioramento del sistema di gestione documentale;

    disponibilità e utilizzo di un sistema di classificazione e codifica;

    conoscenza della metodologia per la creazione di modelli logico-informativi concettuali che riflettano la relazione delle informazioni;

    creazione di matrici di informazioni su supporti informatici, che richiedono un supporto tecnico moderno.

Questo concetto è praticamente implementato in due fasi.

1 ° fase - esame di tutte le divisioni funzionali dell'azienda al fine di:

    comprendere le specificità e la struttura delle proprie attività;

    costruire un diagramma dei flussi di informazioni;

    analizzare il sistema di gestione documentale esistente;

    definire oggetti informativi e la corrispondente composizione di attributi (parametri, caratteristiche) che ne descrivono le proprietà e lo scopo.

2a fase - costruzione di un modello di dati logico-informativo concettuale basato sui risultati dell'indagine di 1a fase. In questo modello, tutte le connessioni tra gli oggetti e i loro attributi devono essere stabilite e ottimizzate. Il modello logico dell'informazione è la base su cui verrà creato il database.

Supporto tecnico - una serie di mezzi tecnici destinati al funzionamento del sistema informativo, nonché la relativa documentazione per tali mezzi e processi tecnologici

Il complesso dei mezzi tecnici è costituito da:

    computer di qualsiasi modello;

    dispositivi per raccogliere, accumulare, elaborare, trasmettere e trasmettere informazioni;

    dispositivi di trasmissione dati e linee di comunicazione;

    apparecchiature e dispositivi per ufficio per il recupero automatico di informazioni;

    materiali operativi, ecc.

La documentazione formalizza la selezione preliminare dei mezzi tecnici, l'organizzazione del loro funzionamento, il processo tecnologico di elaborazione dei dati, le apparecchiature tecnologiche. La documentazione può essere suddivisa approssimativamente in tre gruppi:

    a livello di sistema, inclusi standard statali e di settore per il supporto tecnico;

    specializzato, contenente una serie di metodi per tutte le fasi di sviluppo del supporto tecnico;

    riferimento normativo, utilizzato durante l'esecuzione di calcoli per il supporto tecnico.

Ormai si sono sviluppate due principali forme di organizzazione del supporto tecnico (forme di utilizzo di mezzi tecnici): centralizzata e parzialmente o completamente decentralizzata.

Il supporto tecnico centralizzato si basa sull'uso di grandi computer e centri di calcolo nel sistema informativo. Questa forma di organizzazione facilita la gestione e l'attuazione della standardizzazione, ma riduce la responsabilità e l'iniziativa del personale.

Il decentramento dei mezzi tecnici implica l'implementazione di sottosistemi funzionali sui personal computer direttamente nei luoghi di lavoro. In questo caso, è richiesta una maggiore responsabilità personale da parte del personale, è più difficile per la direzione implementare la standardizzazione.

Attualmente è più diffuso un approccio parzialmente decentralizzato: l'organizzazione del supporto tecnico basato su reti distribuite costituite da personal computer e un mainframe per l'archiviazione di database comuni a qualsiasi sottosistema funzionale.

Matematica e software - un insieme di metodi matematici, modelli, algoritmi e programmi per l'attuazione degli scopi e degli obiettivi del sistema informativo, nonché il normale funzionamento del complesso dei mezzi tecnici.

Ai fondi software si riferiscono:

    strumenti per modellare i processi di gestione;

    compiti di gestione tipici;

    metodi di programmazione matematica, statistica matematica, teoria delle code, ecc.

Parte software include prodotti software a livello di sistema e speciali, nonché documentazione tecnica.

PER software a livello di sistema comprende complessi di programmi rivolti agli utenti e progettati per risolvere problemi tipici dell'elaborazione delle informazioni. Servono per espandere la funzionalità dei computer, controllare e gestire il processo di elaborazione dei dati.

Software speciale è un insieme di programmi sviluppati durante la creazione di un sistema informativo specifico. Comprende pacchetti software applicativi (APP) che implementano i modelli sviluppati con diversi gradi di adeguatezza, riflettendo il funzionamento di un oggetto reale.

La documentazione tecnica per lo sviluppo del software dovrebbe contenere una descrizione dei compiti, il compito per l'algoritmo, il modello economico e matematico del problema, esempi di test.

Supporto organizzativo È un insieme di metodi e mezzi che regolano l'interazione dei lavoratori con i mezzi tecnici e tra di loro nel processo di sviluppo e funzionamento dell'IS.

Il supporto organizzativo implementa le seguenti funzioni:

    analisi del sistema di gestione dell'organizzazione esistente, in cui verrà utilizzato il SI, e identificazione dei compiti da automatizzare;

    preparazione di compiti per la risoluzione su un computer, compresi i termini di riferimento per la progettazione di IS e uno studio di fattibilità della sua efficacia;

    sviluppo di decisioni gestionali sulla composizione e struttura dell'organizzazione, metodologia per la risoluzione dei problemi finalizzata ad aumentare l'efficienza del sistema di gestione.

Il supporto organizzativo viene creato in base ai risultati del sondaggio pre-progetto nella prima fase della creazione del database.

Supporto legale - un insieme di norme giuridiche che determinano la creazione, lo status giuridico e il funzionamento dei sistemi informativi, regolando la procedura per l'ottenimento, la trasformazione e l'utilizzo delle informazioni.

L'obiettivo principale supporto legale è rafforzare lo Stato di diritto. Il quadro giuridico comprende leggi, decreti, decisioni delle autorità statali, ordini, istruzioni e altri documenti normativi di ministeri, dipartimenti, organizzazioni, autorità locali. Nel supporto legale si può distinguere una parte generale che regola il funzionamento di un qualsiasi sistema informativo e una parte locale che regola il funzionamento di un sistema specifico.

Il supporto legale per le fasi di sviluppo di un sistema informativo include la normativa relativa al rapporto contrattuale tra committente e committente e la regolamentazione giuridica degli scostamenti dal contratto.

Il supporto legale delle fasi di funzionamento del sistema informativo comprende:

    stato del sistema informativo;

    diritti, doveri e responsabilità del personale;

    la procedura per la creazione e l'utilizzo delle informazioni, ecc.

Questo insieme di sottosistemi è generale per quasi tutti i tipi di AIS. Tuttavia, la struttura e la complessità dei sottosistemi di supporto dipendono dal tipo di AIS, dal campo di applicazione e da altri fattori. Quindi, il sottosistema di supporto matematico si trova nell'AIS dello sviluppo del software originale - nell'AIS con software standard, è assente. Il sottosistema di supporto legale può essere assente nell'AIS per scopi intra-aziendali - in questo caso, è possibile limitarsi al sottosistema di supporto organizzativo, in cui, tra le altre cose, vengono risolte le questioni di supporto legale; L'AIS per scopi indipendenti, ad esempio i sistemi di servizi di informazione, può avere un sottosistema di supporto legale. Gli AIS, che dispongono di un database fattuale, hanno solo un sottosistema di supporto informativo, in cui può essere necessario risolvere alcuni problemi linguistici. Documentario AIPS ha un sottosistema sviluppato di supporto linguistico, poiché questi sistemi risolvono problemi complessi di garantire la rilevanza semantica delle richieste degli utenti al contenuto dei documenti emessi. E questo, di regola, non sono solo moduli software di analisi morfologica, ma anche un insieme di dizionari e regole per la loro manutenzione.

Gli obiettivi della creazione e dell'implementazione della PI.

Cosa ci si può aspettare dall'implementazione dei sistemi informativi?

L'implementazione dei sistemi informativi può contribuire a:

1. liberazione dei lavoratori dal lavoro di routine e sua accelerazione dovuta all'automazione;

2. sostituzione dei supporti cartacei con dischi o nastri magnetici, che comporta una diminuzione del volume dei documenti su carta, e quindi la possibilità di un'organizzazione più razionale del trattamento delle informazioni su un computer;

3. miglioramento della struttura dei flussi informativi e del sistema di gestione documentale in azienda per effetto della coerenza: unico data entry - utilizzo multiplo e polivalente ";

4. ottenere opzioni più razionali per risolvere problemi di gestione (attraverso l'introduzione di metodi matematici e sistemi intelligenti, ecc.):

    trovare nuove nicchie di mercato;

    ottimizzazione dei costi per la produzione di prodotti e / o servizi;

    ottimizzazione dei rapporti con clienti e fornitori.

Fasi di sviluppo dei sistemi informativi

La storia dello sviluppo della PI è divisa in fasi (Tabella 2), corrispondenti approssimativamente alla numerazione accettata degli obiettivi: l'approccio all'uso della PI sta cambiando.

Tabella 2. Fasi di sviluppo della PI.

Periodo di tempo

Concetto di utilizzo delle informazioni

Tipo di sistemi informativi

Finalità di utilizzo

1950-1960

Flusso cartaceo dei documenti di liquidazione

Sistemi informativi per l'elaborazione dei documenti di liquidazione su macchine contabili elettromeccaniche

Aumentare la velocità di elaborazione dei documenti

Elaborazione semplificata delle fatture e delle buste paga

1960-1970

Aiuto di base nella preparazione dei rapporti

Sistemi informativi gestionali per informazioni sulla produzione

Accelerare il processo di reporting

1970-1980

Controllo di gestione dell'implementazione (vendite)

Sistema di Supporto Decisionale

Sistemi per l'alta dirigenza

Selezione della soluzione più razionale

1980-2000

L'informazione è una risorsa strategica che fornisce un vantaggio competitivo

Sistemi informativi strategici

Uffici automatizzati

Salda sopravvivenza e prosperità

I primi sistemi di informazione sono apparsi a metà del secolo scorso. Negli anni Cinquanta furono progettati per l'elaborazione delle fatture e il calcolo degli stipendi, e furono implementati su macchine contabili elettromeccaniche. Ciò ha comportato una certa riduzione dei costi e dei tempi per la preparazione dei documenti cartacei.

Anni '60 sono caratterizzati da un cambiamento di atteggiamento nei confronti dei sistemi informativi. Le informazioni ottenute da loro iniziarono ad essere utilizzate per rapporti periodici in molti modi. Quel giorno, le organizzazioni avevano bisogno di apparecchiature informatiche generiche in grado di svolgere molte funzioni, e non solo di elaborare fatture e calcolare i salari, come era prima.

Negli anni '70 - primi anni '80. i sistemi informativi iniziano ad essere ampiamente utilizzati come mezzo di controllo di gestione che supporta e accelera il processo decisionale.

Entro la fine degli anni '80. il concetto di utilizzo dei sistemi di informazione sta cambiando di nuovo. Diventano una fonte strategica di informazioni e vengono utilizzati a tutti i livelli di un'organizzazione di qualsiasi profilo. I sistemi informativi di questo periodo, fornendo le informazioni necessarie in tempo, aiutano l'organizzazione a raggiungere il successo nelle sue attività, creare nuovi prodotti e servizi, trovare nuovi mercati di vendita, fornire partner degni, organizzare il rilascio di prodotti a basso prezzo e molto altro ancora.

La moderna concezione del sistema informativo prevede l'uso di un personal computer come principale mezzo tecnico di elaborazione delle informazioni. Nelle grandi organizzazioni, insieme a personal computer la base tecnica del sistema informativo può includere un mainframe o un supercomputer. Inoltre, l'implementazione tecnica del sistema informativo di per sé non significherà nulla se non si tiene conto del ruolo della persona a cui l'informazione è destinata e senza la quale è impossibile riceverla e presentarla.

Postazioni di lavoro da automatizzare

Requisiti di prestazione

Elenco dei rapporti generati

4.4.2. Requisiti per un sistema di pianificazione e controllo della produzione

Il sistema informativo dovrebbe fornire la pianificazione delle risorse aziendali e la gestione della produzione degli ordini.

Requisiti per la funzionalità IS:

1. Gestione della configurazione dei prodotti finiti (FP):

Mantenere le informazioni normative e di riferimento sulla composizione del GP con la possibilità di indicare il periodo di pertinenza del disciplinare e con la possibilità di essere in produzione di GP con più specifiche differenti;

Mantenere le informazioni normative e di riferimento sulla tecnologia di fabbricazione dei prodotti che fanno parte del GP con la possibilità di indicare il periodo di rilevanza delle tecnologie e con la possibilità di essere in produzione del GP con più tecnologie differenti;

2. Gestione delle vendite:

Visualizzazione della cronologia delle relazioni con i clienti;

Registrazione / correzione della domanda del cliente indicando l'elenco delle SOE, volumi, data di spedizione, prezzo di vendita ed eventuali condizioni aggiuntive;

Visualizzare gli indicatori economici correnti (stime dei costi) della SOE ordinata;

3. Pianificazione della produzione:

Formazione di un programma di disponibilità delle apparecchiature che indichi il numero di ore standard disponibili per ogni giorno del periodo pianificato;

Formazione di un piano di produzione indicante il prodotto fabbricato, la sua quantità, le attrezzature utilizzate, la divisione per ogni giorno del periodo di pianificazione;

Formazione di un piano per le esigenze di produzione di materiali e componenti;

Controllo e gestione del carico delle apparecchiature secondo il piano di produzione formato;

Apportare modifiche al piano di produzione durante la sua esecuzione;

Analisi plan-fact del piano di produzione;

4. Gestione della produzione:

Formazione di compiti a turni (ordini) per la fabbricazione di prodotti;



Assegnare / riassegnare agli ordini degli artisti e fissare l'esecuzione degli ordini con l'indicazione del numero di prodotti fabbricati, il numero di prodotti difettosi e le ragioni del matrimonio;

Gestione dello stoccaggio e della movimentazione degli articoli di magazzino (merci e materiali) in produzione;

5. Gestione della fornitura:

Formazione sulla base del piano del fabbisogno di materiali e componenti dell'ordine di acquisto con indicazione del fornitore, nomenclatura delle merci e dei materiali, quantità e tempi di consegna;

Formazione di ordini di acquisto basati su ordini una tantum per merci e materiali dalle divisioni;

Controllo e monitoraggio del processo di completamento degli ordini di acquisto;

Controllo operativo dei residui;

Analisi plan-fact delle consegne;

6. Gestione dei costi:

Formazione del costo pianificato (standard) della SOE;

Fissare i costi di produzione effettivi;

Calcolo del costo effettivo della SOE;

Analisi dei costi effettivi del piano.

Requisiti per il calcolo del costo standard di un ordine

Il costo standard del prodotto e dell'intero ordine viene calcolato utilizzando il seguente metodo:

1. La componente materiale diretto del costo standard di un prodotto è formata sulla base delle informazioni sulla composizione standard di questo prodotto (specifica) e sui prezzi contabili stabiliti per gli articoli di inventario inclusi in questa specifica. Per la specifica, è consentito l'utilizzo di più voci di costo del materiale.

2. L'importo dei salari diretti è calcolato sulla base della composizione operativa standard del prodotto. Sono fissati: la durata standard di ciascuna operazione, la professione del lavoratore richiesta per tale operazione, nonché il grado del lavoratore. Inoltre, il sistema introduce tassi monetari di ore standard per le professioni dei lavoratori e delle loro categorie.

3. Il valore standard dei costi indiretti viene calcolato come percentuale della base specificata (l'importo dei costi diretti per l'elemento specificato).



Per effettuare questo calcolo devono essere disponibili nel Sistema Informativo i seguenti dati:

1. Specifica della fabbricazione del prodotto (nonché la specifica di fabbricazione di tutti i semilavorati di nostra produzione inclusi in questo prodotto);

2. Tecnologia di fabbricazione del prodotto e dei semilavorati in esso contenuti: quali operazioni devono essere eseguite e in che tempo. Inoltre, per ciascuna operazione, vengono fissate la professione e la categoria del lavoratore, necessarie alla sua attuazione (per il rilascio di questo particolare prodotto);

3. Protocollo dei prezzi contabili per beni e materiali usati;

4. Tariffe monetarie dell'orario standard per professioni e gradi.

Requisiti per il calcolo del costo effettivo dell'ordine

Il costo effettivo del prodotto e dell'intero ordine viene calcolato utilizzando il seguente metodo:

1. I costi diretti del materiale per il rilascio del prodotto sono calcolati sulla base dei dati effettivi sul consumo di materiali da parte del negozio per le ridistribuzioni della produzione. In questo caso, viene prima calcolato il costo di tutti i prodotti semilavorati inclusi in questo prodotto. La valutazione complessiva è effettuata secondo la metodologia adottata nel principio contabile dell'impresa.

2. Salario gli addetti alla produzione diretta sono calcolati sulla base dei dati sulla chiusura degli ordini di negozio. Nel caso in cui gli ordini non siano registrati nel SI, i salari si riferiscono ai costi diretti soggetti a distribuzione, es. distribuito ai prodotti fabbricati secondo una certa base.

3. L'ammortamento delle attrezzature di produzione diretta è incluso nei costi diretti se per ciascuna ridistribuzione è indicata l'attrezzatura (macchina utensile) utilizzata in questa ridistribuzione.

4. Costi diretti da allocare:

Materiali di base consumati meno spesso rispetto a ciascuna ridistribuzione (ad esempio, prodotti chimici, il cui tasso per unità di produzione è così piccolo che non ha senso tenere conto del loro consumo alternativo anche a questo ritmo);

Salari dei lavoratori in assenza di informazioni sulla loro distribuzione per fatturato;

Ammortamento dell'attrezzatura diretta se è disponibile solo l'importo mensile totale senza ripartizione per ridistribuzione.

Tali costi sono attribuiti agli articoli prodotti in base alla base di distribuzione selezionata (ad esempio, in proporzione ai costi diretti dei materiali).

1. Costi generali di produzione (conto 25 BU): sono distribuiti ai manufatti in proporzione alla base distributiva selezionata. La quota di tali spese può o meno rimanere nei lavori in corso secondo il principio contabile adottato nell'impresa.

2. Le spese generali di esercizio e di vendita (conti 26 e 44) sono rilevate come spese dell'esercizio corrente e si riferiscono a spese di vendita. La distribuzione di tali costi al costo dei prodotti finiti può essere vista utilizzando un rapporto speciale.

Requisiti di prestazione del sistema informativo

<Раздел должен содержать требования к производительности Информационной системы. Вводится в шаблон>.

Requisiti di affidabilità

<Раздел должен содержать требования к надежности Информационной системы. Например:>

Requisiti per garantire un funzionamento affidabile (stabile) del sistema informativo

Il funzionamento affidabile (stabile) del Sistema Informativo deve essere assicurato dall'attuazione da parte del Cliente di un insieme di misure organizzative e tecniche, il cui elenco è di seguito riportato:

1. Organizzazione dell'alimentazione ininterrotta delle apparecchiature tecniche;

2. Utilizzo di software con licenza;

3. Attuazione regolare delle raccomandazioni del Ministero del lavoro e dello sviluppo sociale della Federazione Russa, esposte nella Risoluzione del 23 luglio 1998 "Sull'approvazione degli standard di tempo standard interindustriali per il lavoro sulla manutenzione dei personal computer e delle apparecchiature per ufficio e del supporto software";

4. Adempimento regolare dei requisiti di GOST 51188-98. "Protezione delle informazioni. Software per testare la presenza di virus informatici ";

5. Backup periodico delle banche dati del Sistema Informativo mediante il Sistema Informativo stesso o mediante il sistema di gestione delle banche dati utilizzato.

Figura: 6.2.
  • (Sistema informativo aziendale)
  • Outsourcing dei sistemi informativi aziendali
    L'esternalizzazione delle funzioni produttive e dei processi aziendali basati sui sistemi informativi aziendali consente di utilizzare le ultime realizzazioni e le "best practice" del management moderno. L'implementazione dei sistemi informativi aziendali è al centro della riprogettazione dei processi aziendali (Processo di business...
    (Outsourcing e outstaffing: tecnologie di alta gestione)
  • Modelli di integrazione dei sistemi informativi aziendali
    I modelli di integrazione dei sistemi informativi rappresentano il livello superiore della classificazione dei modelli di progettazione. Analogamente ai modelli di livelli inferiori di classificazione, un gruppo di modelli strutturali si distingue tra i modelli di integrazione. I modelli strutturali descrivono i componenti principali di un singolo integrato ...
    (Introduzione all'architettura software)
  • COMPITI FUNZIONALI DEL SISTEMA INFORMATIVO DELL'IMPRESA ED I MODULI BASE DEI MODERNI SISTEMI INFORMATIVI DELL'IMPRESA. INTEGRAZIONE DEI MODULI
    Il significato significativo del concetto di modulo presuppone un confronto di sottosistemi funzionali, compiti funzionali con un approccio basato su compiti funzionali con i moduli principali della moderna Figura: 6.2. Confronto di compiti funzionali con i principali moduli dei moderni sistemi informativi ICISP di un'impresa, ...
    (Sistema informativo aziendale)
  • CONCETTO, STORIA DELLO SVILUPPO E CLASSIFICAZIONE DEI SISTEMI INFORMATIVI DELL'IMPRESA. SISTEMI INFORMATIVI AZIENDALI INTEGRATI DELL'IMPRESA
    Il concetto e la classificazione dei sistemi informativi cambiano nel corso del loro sviluppo storico. Tuttavia, l'obiettivo rimane costante ed è associato al raggiungimento dell'efficienza della gestione aziendale. L'efficacia della gestione aziendale dipende dall'interazione di molti fattori, tra i quali: filosofico, storico, ...
    (Sistema informativo aziendale)
  • CARATTERISTICHE DELLE MODERNE TECNOLOGIE INFORMATICHE NEI SISTEMI INFORMATIVI DELL'IMPRESA
    TECNOLOGIE MODERNE PER L'ORGANIZZAZIONE DELL'INSERIMENTO DEI DATI NEI SISTEMI INFORMATIVI AZIENDALI Le informazioni sulle transazioni commerciali dovrebbero essere inserite tempestivamente nel database operativo da qualsiasi fonte della sua origine. Ciò organizzerà efficacemente l'ulteriore elaborazione dei dati nelle informazioni ...
    (Sistema informativo aziendale)


  • Interrelazione dei sottosistemi informativi aziendali

    Come sono sistemi di informazione all'interno dell'azienda? Il solito modo per compagnia russa di medie dimensioni - per iniziare l'implementazione della tecnologia dell'informazione con l'automazione del lavoro del reparto contabilità, del reparto del personale e del flusso di lavoro. I dati di questi sistemi sono i più formalizzati, i processi sono facilmente automatizzati. I pacchetti ampiamente diffusi "1C: Accounting", "Boss: Funzionario del personale", "LanDocs", "LanStaff", "Salary", ecc. Consentono di costruire se stessi con qualsiasi applicazione e, quindi, di integrarli nel sistema informativo generale dell'azienda. Figura: 7.1 mostra come sono collegati tra loro i moduli del sistema informativo aziendale. Il modulo TPS serve i principali processi di produzione e supporto e di solito è la fonte principale per gli altri. moduli informativi... ESS è il principale destinatario dei dati e dei sistemi interni dall'ambiente esterno.


    Figura: 7.1.

    Anche altri sistemi scambiano dati. E qui sorge una delle domande più difficili per un leader: ricerca del grado di integrazione ottimale... Si è tentati di avere un sistema completamente integrato, ma tale integrazione richiede molto tempo e costa un sacco di soldi. Ed è meglio nemmeno dire quanto costa mantenere un tale sistema. Pertanto, le esigenze di sistemi integrati devono essere valutate rispetto alle difficoltà e al costo dei circuiti integrati su larga scala. Non esiste un livello standard di integrazione o centralizzazione - ogni leader deve indipendentemente (o con l'aiuto di una società di consulenza) per risolvere questo difficile problema.

    Collegamenti tra DSS e TPS, KWS,

    LA CAMPANA

    C'è chi ha letto questa notizia prima di te.
    Iscriviti per ricevere gli ultimi articoli.
    E-mail
    Nome
    Cognome
    Come vuoi leggere The Bell
    Niente spam