Wprowadzenie

Rozważana praca została napisana na podstawie Donieck OJSC Donetsk Manufactory dla sklepu Cleonelly.

Jedną z wiodących działalności Donieckiej Manufaktury OJSC jest produkcja szerokiej gamy odzieży, głównie szlafroków, pościeli i ręczników. Ponadto firma produkuje barwioną przędzę bawełnianą do tkania i dziania.

Rozwój zautomatyzowanych technologii informacyjnych idzie w parze z pojawieniem się nowych rodzajów środków technicznych służących do przetwarzania i przekazywania informacji, doskonalenia form organizacyjnych korzystania z komputerów, nasycania infrastruktury nowymi środkami komunikacji. Rozwój relacji rynkowych doprowadził do pojawienia się nowych rodzajów działalności gospodarczej, a przede wszystkim do powstania firm zajmujących się biznesem informacyjnym, rozwoju technologii informatycznych, ich doskonalenia, upowszechnienia się komponentów zautomatyzowanych technologii informatycznych, w szczególności oprogramowania automatyzującego procesy informacyjne i obliczeniowe. Obejmują również technologię komputerową, komunikację, sprzęt biurowy oraz specyficzne rodzaje usług - usługi informacyjne, techniczne i doradcze, szkolenia itp. Przyczyniło się to do szybkiego rozpowszechnienia i efektywnego wykorzystania technologii informacyjnych w zarządzaniu i procesach produkcyjnych, niemal do ich wszechobecności i ogromnej różnorodności.

Przedsiębiorstwa zajmujące się projektowaniem i rozwojem urządzeń o różnym przeznaczeniu obecnie szeroko stosują różne środki zarówno projektowania komputerowego - CAD (CAD), jak i monitorowania procesów produkcyjnych - ACS (SCADA / DCS). Jednak w przypadku urządzeń własnej konstrukcji konieczne jest opracowanie własnych sposobów monitorowania ich działania i analizy jakości wyrobów.

Proces technologiczny rozliczania produktów w magazynie w sklepie Cleanelly obejmuje etap prowadzenia ewidencji sprzedanych produktów.

Celem tego projektu dyplomowego jest wdrożenie zautomatyzowanej stacji roboczej (AWP), która umożliwia rozliczanie produktów w magazynie sklepu

Aby osiągnąć powyższy cel, konieczne jest rozwiązanie następujących zadań:

¾ analizować procesy biznesowe sklepu;

¾ zbadać przepływy informacji pojawiające się na etapie dostawy opracowywanego produktu;

¾ opracowywać koncepcyjne i logiczne modele danych;

¾ opracować oprogramowanie do automatycznej stacji roboczej do rozliczania produktów

¾ ocenić efektywność ekonomiczną systemu informatycznego.

1 Rozwój wymagań oprogramowania

1.1 Analiza istniejących rozwiązań

Obecnie istnieje szeroka gama firm, które łączą zarówno bezpośredni rozwój produktu, jak i rozwój systemów sterowania dla tych produktów. Takie systemy są rozwijane przez tak znane firmy jak 1: C Enterprise i Zvezda. W takich systemach prowadzona jest kontrola i rozliczanie materiałów oraz przetwarzanie otrzymanych informacji.

„1C: Enterprise” to system zastosowanych rozwiązań zbudowany na tych samych zasadach i na jednej platformie technologicznej. Menedżer może wybrać rozwiązanie, które odpowiada aktualnym potrzebom przedsiębiorstwa i będzie się rozwijało wraz z rozwojem przedsiębiorstwa lub rozwojem zadań automatyzacji.

System oprogramowania 1C: Enterprise jest przeznaczony do rozwiązywania szerokiego zakresu zadań z zakresu księgowości i automatyzacji zarządzania, przed którymi stają dynamicznie rozwijające się nowoczesne przedsiębiorstwa. Rozwiązanie rzeczywistych problemów rachunkowości i zarządzania Skład programów systemu 1C: Enterprise jest ukierunkowany na rzeczywiste potrzeby przedsiębiorstw. Firma „1C” produkuje szeregowane rozwiązania programowe przeznaczone do automatyzacji typowych zadań księgowych i zarządczych w przedsiębiorstwach. Charakterystyczną cechą rozwiązań edycji 1C jest dokładne badanie składu funkcjonalności zawartych w rozwiązaniach standardowych. Firma „1C” analizuje doświadczenia użytkowników korzystających z programów systemu „1C: Enterprise” i monitoruje zmiany ich potrzeb.

Do głównych zalet mojego systemu Hurtowni należy relatywnie niski koszt wdrożenia tego systemu, a także szereg innych zalet:

¾ Niezawodność tworzonych aplikacji. Pakiet oprogramowania (PC) musi być odporny nie tylko na błędy użytkownika, ale także awarie w systemie komunikacyjnym.

¾ Łatwość obsługi interfejsu;

¾ Wysoki poziom bezpieczeństwa systemu, co oznacza nie tylko kontrolę nad dostępnością określonych zasobów systemu i bezpieczeństwem informacji na wszystkich etapach pracy, ale także śledzenie wykonywanych czynności z dużym stopniem niezawodności.

1.2 Analiza domeny

Specyfika analizy obszaru tematycznego polega na tym, że pozwala zobaczyć cały zestaw operacji organizacji.

CASE jest przeznaczony do analizy i reorganizacji procesów biznesowych. – Wszystkie narzędzia najwyższego poziomu Fusion Process Modeler (BPwin) obsługujące metodologie IDEF0 (model funkcjonalny), DFD (Diagram przepływu danych) i IDEF3 (Diagram przepływu pracy). BPwin to potężne oprogramowanie do modelowania, które pozwala analizować, dokumentować i planować zmiany w złożonych procesach biznesowych. BPwin oferuje narzędzie do zbierania wszelkich istotnych informacji o działalności przedsiębiorstwa i graficznego przedstawiania tych informacji w postaci spójnego i spójnego modelu.

Pod względem funkcjonalności systemu. W ramach metodologii IDEF0 (Integration Definition for Function Modeling) proces biznesowy jest reprezentowany jako zestaw elementów pracy, które współdziałają ze sobą, a informacje, zasoby ludzkie i produkcyjne zużywane przez każdą pracę są wyświetlane. Model funkcjonalny ma na celu opisanie istniejących procesów biznesowych w przedsiębiorstwie (tzw. Model AS-IS) oraz stanu idealnego – do czego dążyć (model TO-BE). Metodologia IDEF0 nakazuje budowę hierarchicznego systemu diagramów, tj. pojedyncze opisy fragmentów systemu. Najpierw dokonuje się opisu systemu jako całości i jego interakcji ze światem zewnętrznym (diagram kontekstowy), po czym następuje dekompozycja funkcjonalna – system jest podzielony na podsystemy, a każdy system jest opisany osobno (diagramy dekompozycji). Następnie każdy podsystem jest podzielony na mniejsze i tak dalej, aby osiągnąć pożądany poziom szczegółowości.

Jeżeli w procesie modelowania konieczne jest podkreślenie specyfiki technologii przedsiębiorstwa, BPwin umożliwia przejście do dowolnej gałęzi modelu na notację DFD lub IDEF3. Diagramy Data Flow Diagramming (DFD) mogą uzupełniać to, co zostało już odzwierciedlone w modelu IDEF3, ponieważ opisują przepływy danych, umożliwiając śledzenie wymiany informacji między funkcjami biznesowymi w systemie. Jednocześnie diagramy DFD ignorują interakcje między funkcjami biznesowymi.

Pod względem kolejności wykonywanych prac. Jeszcze dokładniejszy obraz można uzyskać uzupełniając model diagramami IDEF3. Ta metoda zwraca uwagę na kolejność wykonywania zdarzeń. Elementy logiki zawarte są w IDEF3, co pozwala modelować i analizować alternatywne scenariusze rozwoju procesu biznesowego.

Aby rozważyć procesy biznesowe w magazynie sklepu, należy użyć tylko dwóch metodologii IDEF0 i DFD. Proces modelowania systemu w IDEF0 rozpoczyna się od zdefiniowania kontekstu, tj. najbardziej abstrakcyjny poziom opisu systemu lub procesów biznesowych w ogóle.

Model IDEF0 ... Aby przestudiować procesy biznesowe „Formowanie zamówienia dostawcy”, „Odbiór towarów”, „Wydanie towarów”, rozważ diagramy przedstawione w postaci diagramu IDEF0. System IDEF0 jest przedstawiany jako zbiór interaktywnych działań lub funkcji.

Metodologia IDEF0 opiera się na czterech głównych koncepcjach.

Pierwsza to koncepcja blok funkcjonalny (Pole aktywności) ... Blok funkcjonalny jest przedstawiony graficznie w postaci prostokąta i uosabia określoną funkcję w ramach rozważanego systemu

Każda z czterech stron bloku funkcjonalnego ma swoje określone znaczenie (rolę), podczas gdy:

Górna strona to Kontrola;

Lewa strona jest ustawiona na „Wejście”;

Prawa strona jest ustawiona na Wyjście;

Wadą jest „mechanizm”.

Drugim „wielorybem” metodologii IDEF0 jest koncepcja łuku interfejsu (strzałka). Graficzne przedstawienie łuku interfejsu jest jednokierunkową strzałką. Każdy łuk interfejsu musi mieć własną nazwę (etykieta strzałki). Za pomocą łuków interfejsów wyświetlane są różne obiekty, które w pewnym stopniu determinują procesy zachodzące w systemie. W tym przypadku strzałki, w zależności od tego, w którą stronę prostokąta roboczego wchodzą lub którą opuszczają, są podzielone na:

Strzałki wejściowe (umieszczone po lewej stronie bloku funkcjonalnego) - reprezentują dane lub obiekty, które ulegają zmianie podczas wykonywania pracy;

Strzałki kontrolne (zawarte w górnej części bloku funkcjonalnego) - przedstawiają zasady i ograniczenia, z powodu których wykonywana jest praca;

Strzałki wyjścia (wyjście z prawej strony bloku funkcjonalnego) - reprezentują dane lub obiekty, które pojawiają się w wyniku pracy;

Strzałki mechanizmu (zawarte w dolnej krawędzi bloku funkcjonalnego) - reprezentują zasoby (na przykład sprzęt, zasoby ludzkie).

Trzecią podstawową koncepcją standardu IDEF0 jest Dekompozycja. Zasada rozkładu jest stosowana przy rozbiciu złożonego procesu na jego funkcje składowe.

Dekompozycja pozwala na stopniowe i ustrukturyzowane przedstawienie modelu systemu w postaci hierarchicznej struktury poszczególnych diagramów, dzięki czemu jest on mniej przeciążony i łatwiejszy do przyswojenia.

Ostatnią z koncepcji IDEF0 jest Glosariusz. Dla każdego z elementów IDEF0: diagramów, bloków funkcjonalnych, łuków interfejsów, istniejący standard zakłada stworzenie i utrzymanie zestawu odpowiednich definicji, słów kluczowych, narracji itp., Które charakteryzują obiekt wyświetlany przez ten element. Zestaw ten nazywany jest glosariuszem i jest opisem istoty tego elementu.

Rozważ diagramy procesów biznesowych zachodzących w magazynie sklepu OJSC DMM „Cleonelly”:

Dla ogólnej widoczności systemu konieczne jest skonstruowanie kontekstu „Aktywność magazynu przedsiębiorstwa” (patrz Rysunek 1.1).

Rysunek 1.1 - Diagram „Działalność magazynowa przedsiębiorstwa”

Po ustaleniu kontekstu następuje dekompozycja, tj. budowanie kolejnych diagramów w hierarchii.

Każdy kolejny diagram to bardziej szczegółowy opis jednej z prac z wyższego diagramu. Przykład dekompozycji pracy kontekstualnej pokazano na rysunku 1.2. Tym samym cały system jest podzielony na podsystemy o wymaganym poziomie szczegółowości, system ten podzielony jest na trzy poziomy.

Rysunek 1.2 - Diagramy dekompozycji pierwszego poziomu

Rysunek 1.3 - Diagram „Odprawa towarów”

Rysunek 1.4 - Diagram „Wydanie towaru”

Rysunek 1.5 - Diagram „Wysyłanie towarów”

DFD. Metodologia ta opiera się na budowie modelu analizowanego SI - projektowanego lub faktycznie istniejącego. Zgodnie z metodologią model systemu definiuje się jako hierarchię diagramów przepływu danych (DFD), opisującą asynchroniczny proces przekształcania informacji z wejścia do systemu na wyjście dla użytkownika. Diagramy DFD są zwykle budowane w celu wizualizacji bieżącej pracy systemu przepływu pracy organizacji. Najczęściej diagramy DFD są wykorzystywane jako uzupełnienie modelu procesu biznesowego zaimplementowanego w IDEF0.

Główne elementy diagramu przepływu danych to:

Podmioty zewnętrzne (przedstawione graficznie jako kwadrat) - oznaczają przedmiot materialny lub osobę będącą źródłem lub odbiorcą informacji. Na przykład: klienci, personel, dostawcy, klienci, magazyn;

Systemy / podsystemy (graficznie wygląda jak prostokąt z zaokrąglonymi narożnikami) - prace oznaczające funkcje lub procesy przetwarzające i zmieniające informacje;

Magazyny danych to abstrakcyjne urządzenie do przechowywania informacji, które można umieścić na dysku w dowolnym momencie, a po chwili można je odzyskać, a także istnieje dowolny sposób umieszczania i pobierania. Ogólnie rzecz biorąc, magazyn danych jest prototypem przyszłej bazy danych, a opis przechowywanych w niej danych powinien być powiązany z modelem informacyjnym;

Strumienie danych - określa informacje przesyłane jakimś połączeniem od źródła do odbiornika. Przepływ danych na diagramie jest reprezentowany przez linię zakończoną strzałką wskazującą kierunek przepływu.

Rozważmy diagram przepływu danych problemu (DFD) Rysunek 1.6. Ten diagram przedstawia ruch dokumentów, gdy „zapotrzebowanie na produkt” dociera do organizacji.

Rysunek 1.6 - Diagram DFD „Wydanie towarów”

Rozważ następujący schemat przepływu danych „Odstęp między produktami” (patrz rysunek 1.7). Pokazuje proces wykonywania pracy i przepływu dokumentów podczas „wydania towaru”.

Rysunek 1.7 - Wykres DFD „Odprawa towarów”

W diagramach przepływu danych wszystkie użyte symbole składają się na duży obraz, który daje jasny obraz tego, jakie dane są używane i jakie funkcje spełnia system przepływu pracy. Jednocześnie często okazuje się, że istniejące przepływy informacji, które są istotne dla działalności firmy, nie są rzetelnie wdrażane i wymagają reorganizacji. *******

Strukturę organizacyjną przedsiębiorstwa zajmującego się sprzedażą wyrobów frotte rozpatrujemy na przykładzie firmy OJSC „Donetsk Manufactura M” sklepu Cleonelly:

W kierunku rozwoju systemów kontroli i rozliczania materiałów potrafią z powodzeniem rozwiązywać problemy:

1. Jest to kontrola nad dostarczanymi i składowanymi towarami.

2. Informacje o dostawcach i konsumentach

3. Zawiera również informacje i operacje dotyczące produktu

4. Zawiera dziennik raportu zwolnionych towarów

5. Zawiera katalog towarów

6. Automatyzacja funkcji magazynowych (przyjęcie, zużycie, odpis, rezerwacja towaru)

7. Rejestracja i przechowywanie faktur za zakupione i sprzedane towary i usługi oraz fakturowanie za przedpłatę z odroczoną płatnością i dostawą towaru

8. Tworzenie faktur i księgowanie wydanych towarów

9. Przeprowadzenie inwentaryzacji magazynów z utworzeniem arkusza zestawienia, akt niedoboru i nadwyżki

10. Tworzenie zestawów towarów

Jak wskazano, głównym obszarem działalności tego przedsiębiorstwa jest sprzedaż wyrobów bawełnianych. Proces projektowania obejmuje wiele etapów starannie opracowanych przez struktury kierownicze przedsiębiorstw projektowych przez cały okres istnienia przedsiębiorstwa. Procesu tego nie można jednocześnie zmienić, gdyż angażuje on wiele działów samego przedsiębiorstwa, zewnętrznych podwykonawców i klientów przedsięwzięcia projektowego. Dlatego przedsiębiorstwa obawiają się wprowadzania systemów informatycznych związanych z procesami zarządzania projektowaniem i rozwojem. Z reguły rosyjskie przedsiębiorstwa wykorzystują własne rozwiązania w tej dziedzinie.

1.3 Zbieranie wymagań

Projektując system informacyjny (IS) „Stanowisko Hurtowni” konieczne było zebranie wymagań, które pomogłyby stworzyć interfejs w taki sposób, aby użytkownik końcowy (pracownik sklepu) czuł się komfortowo w pracy z opracowanym IS.

Opracowywanie wymagań to proces obejmujący czynności wymagane do utworzenia i zatwierdzenia dokumentu specyfikacji wymagań systemowych.

Aby wdrożyć proces automatyzacji ewidencji i kontroli materiałów konieczne jest, aby system informatyczny spełniał następujące wymagania funkcjonalne:

¾ dokumentowanie wyników.

¾ System informacyjny musi być wdrożony jako program oparty na zintegrowanym środowisku Visual Fox Pro.

Program działa w systemie operacyjnym Windows 2000 / NT / XP.

Istnieją cztery główne etapy procesu opracowywania wymagań (rysunek 1.8):

Analiza technicznej wykonalności stworzenia systemu;

Tworzenie i analiza wymagań;

Określenie wymagań i stworzenie odpowiedniej dokumentacji;

Poświadczenie wymagań.

Zbieranie wymagań jest ważnym etapem projektowania oprogramowania, ponieważ to tutaj wszystkie wymagania klientów muszą być poprawnie i poprawnie sformułowane.

1.4 Specyfikacja wymagań

Określenie właściwych wymagań jest prawdopodobnie najbardziej krytycznym krokiem w projekcie oprogramowania. Bardzo ważne jest, aby format projektu był zgodny z wymaganiami oprogramowania opracowanymi przez zespół programistów, w przeciwnym razie wymagania te nie mogą być obsługiwane i prezentowane w oprogramowaniu. Specyfikacja wymagań oprogramowania (SRS) ma kluczowe znaczenie dla całego cyklu życia oprogramowania. Jest to nie tylko dokument pochodny, który definiuje specyfikacje projektu oprogramowania, ale także główny dokument służący do przeprowadzania testów kwalifikacyjnych i akceptacyjnych. Atestacja to ocena jakości pracy kierowników projektów. Określa stopień zgodności oprogramowania z ustalonymi wymaganiami. Specyfikacja SRS działa jako mechanizm rejestrowania wymagań systemowych, które są wykorzystywane jako kryteria atestacji.

Na podstawie SRS dochodzi do porozumienia między klientami a producentami oprogramowania. Specyfikacja SRS w pełni opisuje funkcje, które musi spełniać opracowane oprogramowanie. Pozwala to potencjalnym użytkownikom określić, w jakim stopniu produkt spełnia ich potrzeby, a także sposoby modyfikacji produktu tak, aby był jak najbardziej przydatny w rozwiązywaniu ich problemów.

Skraca czas rozwoju. W przygotowanie specyfikacji SRS zaangażowane są różne grupy w organizacji klienta. Dokładnie badają wszystkie wymagania, jeszcze zanim rozpocznie się faktyczny rozwój projektu. Zmniejsza to prawdopodobieństwo późniejszego przeprojektowania, kodowania i testowania.

Dokładne badanie wymagań specyfikacji SRS może ujawnić przeoczenia, nieporozumienia i niespójności na wczesnym etapie cyklu rozwoju, kiedy problemy są znacznie łatwiejsze do naprawienia niż później.

Specyfikacja SRS staje się podstawą do szacowania kosztów i harmonogramowania. Opis produktu jest prawdziwą podstawą do oszacowania kosztów projektu. W środowisku, w którym istnieje koncepcja formalnej oferty, SRS służy do weryfikacji oszacowania oferty lub ceny.

Dzięki dobrze napisanym specyfikacjom SRS na poziomie organizacji mogą opracowywać znacznie wydajniejsze plany certyfikacji i audytów. W ramach umowy deweloperskiej SRS stanowi punkt odniesienia do oceny zgodności ze specyfikacjami.

Specyfikacja SRS ułatwia przenoszenie oprogramowania nowym użytkownikom, a także instalowanie go na innych komputerach. W ten sposób klienci mogą łatwiej przenosić oprogramowanie do innych działów organizacji, a programistom - przenosić je na innych klientów.

Podstawą modernizacji jest specyfikacja SRS. Ten dokument dotyczy samego produktu, a nie procesu rozwoju projektu, więc można go wykorzystać do rozszerzenia gotowego produktu.

Po zakończeniu procesu definiowania i specyfikowania wymagań konieczne jest przeprowadzenie walidacji wymagań.

Specyfikację wymagań dla projektu oprogramowania należy przedstawić w Załączniku A.

1.5 Poświadczenie wymagań

Walidacja musi wykazać, że wymagania naprawdę definiują system, który klient chce mieć. Walidacja wymagań jest ważna, ponieważ błąd w specyfikacji wymagań może prowadzić do przeróbek systemu i wysokich kosztów, jeśli zostanie wykryty podczas procesu rozwoju systemu lub po jego uruchomieniu.

Podczas procesu atestacji wymagań należy przeprowadzić różnego rodzaju sprawdzenia dokumentacji wymagań:

1. Sprawdzenie poprawności wymagań.

2. Sprawdzanie spójności.

3. Sprawdź kompletność.

4. Sprawdzenie wykonalności.

Istnieje wiele metod zaświadczania wymagań, które można stosować łącznie lub oddzielnie:

1. Przegląd wymagań.

2. Prototypowanie.

3. Generowanie skryptów testowych.

4. Zautomatyzowana analiza spójności.

Najbardziej widoczne dla klienta systemu jest prototypowanie.

Przed rozpoczęciem prototypowania możesz utworzyć schemat przepływu interfejsu użytkownika. Ten diagram służy do badania relacji między głównymi elementami interfejsu użytkownika.

Kolejnym krokiem w walidacji wymagań jest bezpośrednie prototypowanie.

Prototyp oprogramowania to częściowa lub możliwa implementacja proponowanego nowego produktu. Prototypy pozwalają zrealizować trzy główne zadania: wyjaśnienie i dokończenie procesu formułowania wymagań, zbadanie alternatywnych rozwiązań oraz stworzenie produktu końcowego.

Prototyp menu głównego tego modułu pokazano na rysunku 1.9.

1.6 Wybór metodologii projektowania systemu informatycznego

Istota strukturalnego podejścia do rozwoju SI polega na jego dekompozycji (rozbiciu) na zautomatyzowane funkcje: system jest podzielony na podsystemy funkcjonalne, które z kolei są podzielone na podfunkcje, podzielone na zadania i tak dalej. Proces partycjonowania jest kontynuowany do określonych procedur. Jednocześnie zautomatyzowany system zachowuje całościową wizję, w której wszystkie elementy składowe są ze sobą połączone.

Wszystkie najpowszechniejsze metodologie podejścia strukturalnego opierają się na kilku ogólnych zasadach. Następujące zasady są używane jako dwie podstawowe zasady:

Divide and Conquer - zasada rozwiązywania złożonych problemów poprzez rozbicie ich na wiele mniejszych, niezależnych problemów, które są łatwe do zrozumienia i rozwiązania;

Zasada hierarchicznego uporządkowania to zasada organizowania części składowych problemu w hierarchiczne struktury drzewiaste z dodaniem nowych szczegółów na każdym poziomie.

Analiza strukturalna wykorzystuje głównie dwie grupy narzędzi, które ilustrują funkcje pełnione przez system oraz relacje między danymi. Każda grupa funduszy odpowiada określonym typom modeli (diagramom), z których najpowszechniejsze są następujące:

Modele SADT (Structured Analysis and Design Technique) i powiązane schematy funkcjonalne;

Diagramy przepływu danych DFD (Data Flow Diagrams);

Diagramy relacji encji (ERD (Entity-Relationship Diagrams)).

Na etapie projektowania IS modele są rozbudowywane, udoskonalane i uzupełniane o diagramy odzwierciedlające strukturę oprogramowania: architekturę oprogramowania, schematy blokowe programu i diagramy ekranowe.

Wymienione modele łącznie dają pełny opis IP, niezależnie od tego, czy istnieje, czy jest nowo opracowany. Skład diagramów w każdym konkretnym przypadku zależy od wymaganej kompletności opisu systemu.

2 PROJEKTOWANIE SYSTEMU INFORMACYJNEGO

2.1 Projekt architektoniczny

Podczas tworzenia dowolnego złożonego systemu informatycznego krytycznym aspektem jest jego architektura, w której przedstawia koncepcyjną wizję struktury przyszłych procesów funkcjonalnych i technologii na poziomie systemu i we wzajemnych połączeniach. Zwykle złożone systemy informacyjne organizacji są projektowane jako kompozycja współdziałających komponentów wysokiego poziomu, które same mogą być systemami. Architektura systemu informatycznego organizacji sprawia, że \u200b\u200bsystem jest łatwiejszy do zrozumienia, definiując jego funkcjonalność i strukturę w sposób, który ujawnia decyzje projektowe i pozwala obserwatorowi zadawać pytania dotyczące spełnienia wymagań projektowych, alokacji funkcjonalności i wdrażania komponentów.

Architektura systemu informatycznego organizacji jest modelem tego, jak technologia informacyjna będzie wspierać główne cele i strategię rozwoju zautomatyzowanego obiektu. Pozwala myśleć krytycznie i wyartykułować wizję tego, jak powinny być zorganizowane zintegrowane zestawy systemów informacyjnych, aby osiągnąć te cele. Architektura systemu informacyjnego opisuje, w jaki sposób systemy informacyjne, aplikacje i ludzie pracują w organizacji w jednolity, ujednolicony sposób.

Zatem architektura systemu informacyjnego obejmuje ogólnie przyjęty zestaw komponentów, które stanowią „bloki konstrukcyjne” systemu informacyjnego. Te „elementy składowe” i ich cechy są zdefiniowane na odpowiednim poziomie szczegółowości, aby sprostać potrzebom decyzji planistycznych.

Projektując nowoczesne systemy informacyjne organizacji, ich architektura powinna być rozwijana z uwzględnieniem wielu interesariuszy, powinna być zrozumiała dla użytkowników, umożliwiać programistom sporządzenie planu i harmonogramów systemu, umożliwiać definiowanie kluczowych interfejsów, funkcji i technologii, a także umożliwiać oszacowanie harmonogramu i budżetu projektu. Wymaga to od architektów nowoczesnych systemów informatycznych odpowiedzialności za stworzenie satysfakcjonującej i wykonalnej koncepcji systemu na jak najwcześniejszym etapie jego rozwoju, zachowanie integralności tej koncepcji przez cały okres rozwoju oraz określenie przydatności powstałego systemu do użytku przez klienta. Z drugiej strony architektura systemu informacyjnego jest procesem opisywania architektur systemów informatycznych z wystarczającą szczegółowością, aby uczynić je bardziej użytecznymi przy projektowaniu systemów informatycznych.

Badanie doświadczeń zagranicznych pokazuje, że w krajach rozwiniętych przy opracowywaniu architektury systemu informatycznego należy spełnić następujące warunki:

¾ skupienie się na misji organizacji;

¾ skupienie się na wymaganiach;

¾ nastawienie na rozwój;

¾ zdolność adaptacji;

¾ potrzeba elastyczności.

Spełnienie tych wszystkich warunków pozwala na doskonalenie i sprawność architektury systemu informatycznego organizacji.

Główne obecnie wdrażane architektury oprogramowania to:

¾ serwer plików;

¾ klient-serwer;

¾ wielopoziomowy.

Serwer plików ... Ta architektura scentralizowanych baz danych z dostępem do sieci polega na wyznaczeniu jednego z komputerów w sieci jako serwera dedykowanego, na którym będą przechowywane pliki scentralizowanej bazy danych. Zgodnie z żądaniami użytkowników pliki z serwera plików są przesyłane na stacje robocze użytkowników, gdzie odbywa się większość przetwarzania danych. Centralny serwer pełni głównie rolę magazynu plików, nie uczestnicząc w samym przetwarzaniu danych. Po zakończeniu prac użytkownicy kopiują pliki z przetworzonymi danymi z powrotem na serwer, skąd mogą zostać pobrane i przetworzone przez innych użytkowników. Taka organizacja utrzymania danych ma szereg wad, na przykład gdy wielu użytkowników ma dostęp do tych samych danych w tym samym czasie, wydajność pracy gwałtownie spada, ponieważ konieczne jest zaczekanie, aż użytkownik pracujący z danymi zakończy swoją pracę. W przeciwnym razie zmiany dokonane przez niektórych użytkowników mogą zostać nadpisane przez zmiany wprowadzone przez innych użytkowników.

Klient-serwer ... Koncepcja ta opiera się na założeniu, że oprócz przechowywania plików bazy danych, serwer centralny powinien wykonywać większość przetwarzania danych. Użytkownicy uzyskują dostęp do serwera centralnego za pomocą specjalnego języka SQL (Structured Query Language), który opisuje listę zadań wykonywanych przez serwer. Żądania użytkowników są odbierane przez serwer i generują w nim procesy przetwarzania danych. W odpowiedzi użytkownik otrzymuje już przetworzony zbiór danych. Nie cały zestaw danych jest przesyłany między klientem a serwerem, jak ma to miejsce w technologii serwera plików, ale tylko te dane, których potrzebuje klient. Zapytanie użytkownika, które ma tylko kilka wierszy, może generować przetwarzanie danych obejmujące wiele tabel i miliony wierszy. W odpowiedzi klient może otrzymać tylko kilka numerów. Technologia klient-serwer pozwala uniknąć przesyłania ogromnych ilości informacji przez sieć, przenosząc całe przetwarzanie danych na serwer centralny. Ponadto rozważane podejście pozwala uniknąć konfliktów zmian tych samych danych przez wielu użytkowników, co jest typowe dla technologii serwera plików. Technologia klient-serwer zapewnia spójną modyfikację danych przez wielu klientów, zapewniając automatyczną integralność danych. Te i inne zalety sprawiły, że technologia klient-serwer stała się bardzo popularna. Wadą tej technologii są wysokie wymagania dotyczące wydajności serwera centralnego. Im więcej klientów uzyskuje dostęp do serwera i im większa ilość przetwarzanych danych, tym potężniejszy musi być serwer centralny.

Na podstawie tych rozważań, projektując architekturę AWS, jako podstawę przyjęto technologię klient-serwer. Diagramy rozmieszczenia pokazują fizyczne relacje między oprogramowaniem a komponentami sprzętowymi systemu).

2.2 Projektowanie interfejsu systemu informatycznego

Interfejs użytkownika jest często rozumiany jedynie jako wygląd programu. Jednak w rzeczywistości użytkownik postrzega przez siebie cały system jako całość, co oznacza, że \u200b\u200btakie rozumienie go jest zbyt wąskie. W rzeczywistości interfejs użytkownika obejmuje wszystkie aspekty projektowania, które mają wpływ na interakcję między użytkownikiem a systemem. Użytkownik widzi nie tylko ekran. Interfejs użytkownika składa się z wielu komponentów, takich jak:

zestaw zadań użytkownika, które rozwiązuje za pomocą systemu;

sterowanie systemem;

nawigacja między blokami systemu;

projekt wizualny ekranów programów.

Oto niektóre z najważniejszych korzyści biznesowych dobrego interfejsu użytkownika:

zmniejszenie liczby błędów użytkownika;

obniżenie kosztów obsługi systemu;

ograniczenie utraty produktywności pracowników podczas wdrażania systemu i szybsze odzyskiwanie utraconej produktywności;

poprawa morale pracowników;

obniżenie kosztów zmiany interfejsu użytkownika na żądanie użytkowników;

dostępność funkcjonalności systemu dla maksymalnej liczby użytkowników.

Baza hurtowa AWP jest tworzona jako aplikacja w technologii klient-serwer.

2.2.1 Interfejs użytkownika programu sterującego

Głównym modułem „AWP Wholesale Base” jest moduł Luck.exe, który zapewnia implementację głównej funkcjonalności diagramu przypadków użycia pokazanego na rysunku 1.9 w sekcji 1.4.

Podczas opracowywania systemu informacyjnego jednym z głównych zadań jest stworzenie jak najprostszego i nie załadowanego interfejsu. Jest to interfejs oprogramowania, który pomaga użytkownikom „komunikować się” z systemem informacyjnym, działając jako dialog między użytkownikiem a systemem.

Interfejs programu, część administracyjna:

1. forma startowa programu. Formularz ten jest uruchamiany po uruchomieniu oprogramowania, tworząc tym samym początek dialogu użytkownika z systemem (rysunek 2.3);

2. formularz administracyjny. W tej formie realizowane jest pełne zarządzanie systemem informatycznym tj. dodawanie, usuwanie, zmiana danych w bazie oraz w razie potrzeby przeglądanie i drukowanie raportów (Rys. 2.4);

3. Formularz „Klienci”, dzięki temu formularzowi można zobaczyć pełne informacje o klientach przedsiębiorstwa (rysunek 2.7);

4. Formularz „Dostawcy”, dzięki temu formularzowi można zobaczyć pełne informacje o klientach przedsiębiorstwa (rysunek 2.8).

Część użytkownika interfejsu programu:

W oknie przybycia towaru towar jest przetwarzany. Wybierając tę \u200b\u200bzakładkę formularza, użytkownik musi najpierw

W menu wydatkowym znajdują się operacje wykonywane przez magazyniera w celu wydania i sprzedaży towaru.

W saldach menu zliczane są towary, nazwy towarów znajdujących się na magazynie.

W menu kasjera przechowywane są informacje o przychodzących i wychodzących zleceniach gotówkowych. (Zrzuty ekranu)

2.2.2 Interfejsy użytkownika komponentów sterujących

Rys 2.0 Główne menu programu

Główne okno programu pokazano na rys. 1.9. Jak widać na rysunku, oprócz menu głównego, opisanego już powyżej, będzie ono zawierało również panel sterowania (przyciski „Dochód”, „Zużycie”, „Dostęp”, „Salda”, „Kasjer”, „Przeszacowanie”, „Analizy”, „ Katalogi ”,„ Serwis ”i„ Zakończ program ”).

Rysunek 2.1 Okno menu przyjęcia lub przyjęcia do magazynu.

Rysunek 2.2 Okno menu Zużycie

Rysunek 2.2 Okno menu, które reguluje prawa dostępu do programu.

Rysunek 2.3 Okno menu pozostałej części towaru.

Rysunek 2.4 Okno menu kasy.

Rysunek 2.4 Okno menu Przeszacowanie.

2.3 Projekt bazy danych

Do zaprojektowania bazy danych wykorzystano ERwin 4.0 firmy Computer Associates Int.

ERwin to potężne i łatwe w użyciu narzędzie do projektowania baz danych, które zyskało szeroką akceptację i popularność. Zapewnia najwyższą produktywność podczas tworzenia i utrzymywania aplikacji bazodanowych. W całym procesie - od logicznego modelowania wymagań informacyjnych i reguł biznesowych definiujących bazę danych, po optymalizację modelu fizycznego zgodnie z określonymi cechami - ERwin umożliwia wizualne przedstawienie struktury i głównych elementów bazy danych.

ERwin to nie tylko najlepsze narzędzie do projektowania baz danych, ale także narzędzie do szybkiego ich tworzenia. ERwin optymalizuje model zgodnie z fizycznymi cechami docelowej bazy danych. W przeciwieństwie do innych narzędzi, ERwin automatycznie zachowuje logiczną i fizyczną spójność schematu oraz tłumaczy konstrukcje logiczne, takie jak relacje wiele do wielu, na fizyczne implementacje. Ułatwia projektowanie baz danych. Aby to zrobić, wystarczy stworzyć graficzny model E-R (relacja obiektowa), który spełnia wszystkie wymagania dotyczące danych i wprowadzić reguły biznesowe, aby stworzyć model logiczny, który wyświetla wszystkie elementy, atrybuty, relacje i grupy. Erwin ma dwa poziomy prezentacji modelu - logiczny i fizyczny. Warstwa logiczna to abstrakcyjny widok danych, na niej dane są przedstawiane tak, jak wyglądają w świecie rzeczywistym i można je nazwać tak, jak nazywa się je w świecie rzeczywistym, na przykład „Lojalny klient”, „Dział” lub „Nazwisko pracownika”. Obiekty modelu, które są reprezentowane na poziomie logicznym, nazywane są jednostkami i atrybutami. Poziom logiczny modelu danych jest uniwersalny i nie ma nic wspólnego z konkretną implementacją DBMS. Istnieją trzy podpoziomy logicznego poziomu modelu danych, które różnią się głębokością prezentacji informacji o danych:

Diagram powiązań między podmiotami (ERD);

Model oparty na kluczach (KB);

Model w pełni przypisany (FA).

Diagram encji - relacja zawiera encje i relacje, które odzwierciedlają podstawowe reguły biznesowe domeny. Taki diagram nie jest zbyt szczegółowy, zawiera główne byty i relacje między nimi, które spełniają podstawowe wymagania. Diagram encji - relacja może obejmować relacje wiele do wielu i nie może zawierać opisów kluczy. Zazwyczaj ERD jest używany do prezentacji i dyskusji o strukturach danych z ekspertami dziedzinowymi. Model danych oparty na kluczach to bardziej szczegółowy widok danych. Zawiera opis wszystkich jednostek i kluczy podstawowych i ma na celu przedstawienie struktury danych i kluczy, które odpowiadają obszarowi tematycznemu.

Model logiczny jest najbardziej szczegółową reprezentacją struktury danych: przedstawia dane w trzeciej normalnej formie i obejmuje wszystkie jednostki, atrybuty i relacje (patrz dodatek B).

Fizyczny model danych wręcz przeciwnie, zależy to od konkretnego DBMS, będąc w rzeczywistości wyświetlaniem katalogu systemu. Fizyczna warstwa modelu zawiera informacje o wszystkich obiektach w bazie danych. Ponieważ nie ma standardów dla obiektów bazy danych (na przykład nie ma standardu dla typów danych), fizyczna warstwa modelu zależy od konkretnej implementacji DBMS. W konsekwencji kilka różnych poziomów fizycznych różnych modeli może odpowiadać temu samemu poziomowi logicznemu modelu. Jeśli na poziomie logicznym modelu nie ma większego znaczenia, jaki konkretny typ danych atrybutu (chociaż obsługiwane są abstrakcyjne typy danych), to na poziomie fizycznym modelu ważne jest opisanie wszystkich informacji o konkretnych obiektach fizycznych - tabelach, kolumnach, indeksach, procedurach itp. ... Podział modelu danych na poziomy logiczny i fizyczny pozwala rozwiązać kilka ważnych problemów.

Fizyczny model danych przedstawiono w załączniku B.

2.4 Uzasadnienie wyboru platformy do tworzenia systemu informacyjnego

Visual FoxPro to wizualne środowisko programistyczne dla systemów zarządzania relacyjnymi bazami danych, które są obecnie dostępne w firmie Microsoft. Najnowsza wersja to 9.0. Używa języka programowania FoxPro. Wersja systemu 7.0 może działać na jądrach Windows 9x i NT, wersje 8.0 i 9.0 - tylko w Windows XP, 2000, 2003.

FoxPro (Fox-pro?) Jest jednym z dialektów języka programowania xBase. Służy głównie do rozwoju relacyjnego DBMS, chociaż można go wykorzystać do tworzenia innych klas programów.Jak wspomniano powyżej, język VFP jest silnie rozszerzonym i rozszerzonym językiem xBase. W programie Visual FoxPro językiem programowania, czyli podstawową konstrukcją języka, jest pojęcie klasy. Oryginalna wersja xBase jest językiem czysto ustrukturyzowanym, z podstawową koncepcją procedur i funkcji. W ten sposób nowoczesny język programowania Visual FoxPro pozwala łączyć zarówno „staromodne” programowanie poprzez opisywanie wielu procedur, jak iw stylu OOP, tworząc złożoną hierarchię klas.

Wybrałem ten język programowania, ponieważ zawiera szereg następujących zalet:

¾ Dobrze znany format tabel w bazie danych, który ułatwia wymianę informacji z innymi aplikacjami Microsoft Windows.

Nowoczesna organizacja relacyjnych baz danych, która pozwala na przechowywanie informacji o tabelach baz danych, ich właściwościach, indeksach i relacjach, ustalanie warunków integralności referencyjnej, tworzenie widoków lokalnych i zdalnych, połączeń serwerowych, procedur składowanych wykonywanych w przypadku wystąpienia ponad 50 różnych typów zdarzeń (VFP 7.0-9.0).

Wysoka prędkość pracy z dużymi bazami danych.

Wysoka widoczność pracy z bazami danych: wielofunkcyjne okno Sesja danych pozwala zobaczyć listę otwartych tabel bazy danych, ich relacje, filtry, kolejność indeksów, tryby buforowania, przejść do trybów modyfikacji struktury, pracować z informacjami tabelarycznymi itp.

Wysoka prędkość tworzenia aplikacji przy użyciu kreatorów, projektanta, konstruktorów, trybu podpowiedzi IntelliSense podczas pisania programów, debugowania i testowania programów.

Możliwość tworzenia aplikacji klient-serwer z danymi przechowywanymi na serwerach baz danych Oracle i Microsoft SQL Server oraz innych aplikacjach Microsoft Windows przy użyciu ODBC i OLE

System VFP przeznaczony jest do użytku przez profesjonalnych programistów, nie ma więc sensu rusyfikować jego menu i języka - dla każdego programisty angielska składnia języka algorytmicznego jest bardziej znana niż rosyjska.

2.5 Projektowanie modułów

Przyjrzyjmy się bardziej szczegółowo projektowi jednego z modułów programu i rozważmy na jego przykładzie kroki niezbędne do stworzenia projektu.

Jako przykład rozważę projekt modułu, który implementuje przypadek użycia „Wystawia wniosek o przyjęcie”.

Najpierw opiszmy przepływ zdarzeń, które występują w tym przypadku użycia.

Warunkiem wstępnym przypadku użycia jest otrzymanie żądania od klienta.

5. Przypadek użycia rozpoczyna się w momencie złożenia przez klienta wniosku.

6. Menedżer otwiera formularz dochodu.

7. Kierownik ustala datę złożenia wniosku.

8. Kierownik umieszcza nazwę produktu.

9. Kierownik wpisuje ilość otrzymanego towaru.

10. Kierownik wpisuje kwotę wniosku.

11. Menedżer zamyka formularz.

12. Przypadek użycia się kończy.

Warunkiem końcowym przypadku użycia jest rejestracja aplikacji w systemie i pojawienie się nowego klienta w dzienniku formularza głównego.

Rozważ diagram sekwencji dla tego przypadku użycia. Jak widać na tym diagramie, menadżer otwierając formularz Przybycie powoduje wykonanie kilku akcji - automatycznie (z punktu widzenia managera) wypełnia się data złożenia wniosku. Podczas składania wniosku lista klientów jest uzupełniana z bazy o podstawowe informacje. Następnie menedżer wprowadza wszystkie niezbędne dane i naciska przycisk „Akceptuj”. W takim przypadku wykonywane są następujące czynności. Wszystkie dane są przekazywane do procedury składowanej.

3 Wdrożenie i walidacja systemu informatycznego

3.1 Wdrażanie aplikacji

Wdrożenie aplikacji jest w swej istocie jednym z pracochłonnych etapów dla twórcy systemu informatycznego, ponieważ stawiane przez klienta wymagania muszą być jasno i poprawnie zintegrowane z systemem. Jak dotąd nie ma takiego oprogramowania, które mogłoby „dopasować się” do wymagań tzw. Klienta i zapewnić określony zestaw funkcji do wdrożenia systemu, który spełniałby te wymagania. Dlatego każdy programista musi wybrać optymalne środowisko do rozwoju systemu, ale należy zauważyć, że wdrażając aplikację, nie można obejść się bez pisania kodu programu. To właśnie podczas pisania kodu programu zaimplementowane zostaną określone funkcje, które system musi wykonać. W zależności od wybranego środowiska wdrożenia systemu kod programu będzie wyglądał inaczej, w takim środowisku jak Microsoft Visual FoxPro będzie jeden kod programu, w Visual Basic inny itd.

W tym przypadku aplikacja została zaimplementowana w Microsoft Visual FoxPro.

Poniżej opisane zostaną główne funkcje systemu:

1. Forma wyjściowa systemu. Ten formularz jest formularzem przycisku, a zatem każdy przycisk pełni swoją własną funkcję. Przycisk rejestracji administratora pokazany jest na rysunku 3.1 Przycisk ten realizuje funkcję otwierającą panel administratora, o ile użytkownik ma takie uprawnienia do tego systemu.

2. Przybycie przycisku menu. Przycisk ten pozwala na bieżąco śledzić przychodzące towary do magazynu sklepu Rysunek 3.2.

3. W przycisku menu prowadzona jest ewidencja wydatku towarów wydanych z magazynu Rysunek 3.3.

4. W przycisku menu dostępu regulowane są prawa do korzystania z tego programu, Rys. 3.4.

5. W przycisku menu „Resztki” zapisywane są informacje o przechowywanych materiałach w magazynie sklepu.

6. Przycisk menu kasy przechowuje informacje o przychodzących i wychodzących zleceniach gotówkowych Rysunek 3.6.

7. W menu przeszacowania przycisku dokonuje się zmiany ceny na nową cenę towaru Rys. 3.7.

Rysunek 3.1 - Formularz uruchomienia systemu

Rysunek 3.2 - Forma księgowania przyjęć towarów do magazynu.

Rysunek 3.3 - Forma rozliczenia zwolnionych towarów.

Rysunek 3.4– Formularz regulujący prawa dostępu do programu.

Rysunek 3.5– Forma pozostałości towaru w magazynie.

Rysunek 3.5 - Formularz potwierdzeń i wpływów gotówkowych.

Rysunek 3.6 - Forma operacji na towarach.

Testowanie aplikacji

Testowanie to proces wykonywania programu w celu wykrycia błędów. Testowanie zapewnia:

Wykrywanie błędów;

Wykazanie zgodności funkcji programu z jego celem;

Demonstracja realizacji wymagań dotyczących charakterystyki programu;

Wyświetlanie rzetelności jako wskaźnika jakości programu.

Rysunek 3.2 przedstawia przepływ informacji w procesie testowania.

Na wejściu do procesu testowania znajdują się trzy strumienie:

Tekst programu;

Dane początkowe do uruchomienia programu;

Oczekiwane rezultaty.

Wykonywane są testy i oceniane są wszystkie uzyskane wyniki. Oznacza to, że rzeczywiste wyniki testów są porównywane z oczekiwanymi wynikami. W przypadku znalezienia niezgodności rejestrowany jest błąd i rozpoczyna się debugowanie.

Po zebraniu i ocenie wyników testów rozpoczyna się wyświetlanie jakości i niezawodności oprogramowania. Jeśli regularnie występują poważne błędy, które wymagają zmian projektowych, jakość i niezawodność oprogramowania jest podejrzana i stwierdza się potrzebę wzmocnienia testów.

Wyniki zgromadzone podczas testów można ocenić w bardziej formalny sposób. W tym celu stosuje się modele niezawodności oprogramowania, które przewidują niezawodność w oparciu o rzeczywiste dane dotyczące wskaźnika błędów.

Istnieją 2 zasady testowania oprogramowania:

Testy funkcjonalne (testy czarnoskrzynkowe);

Testy strukturalne (testy typu white box).

Podczas testowania metody „białej skrzynki” znana jest wewnętrzna struktura programu. Przedmiotem testowania nie jest tutaj zewnętrzne, ale wewnętrzne zachowanie programu. Sprawdzana jest poprawność konstrukcji wszystkich elementów programu oraz poprawność ich współdziałania ze sobą.

Testowanie czarnoskrzynkowe (testowanie funkcjonalne) pozwala na uzyskanie kombinacji danych wejściowych, które zapewniają pełną kontrolę wszystkich wymagań funkcjonalnych programu. Produkt programowy jest tutaj traktowany jako „czarna skrzynka”, której zachowanie można określić jedynie poprzez zbadanie jego wejść i odpowiednich wyników.

Zasada „czarnej skrzynki” nie jest alternatywą dla zasady „białej skrzynki”. Jest to raczej podejście uzupełniające, które wykrywa inną klasę błędów.

Testowanie czarnoskrzynkowe zapewnia następujące kategorie błędów:

Nieprawidłowe lub brakujące funkcje;

Błędy interfejsu;

Błędy w zewnętrznych strukturach danych lub podczas uzyskiwania dostępu do zewnętrznej bazy danych;

Charakterystyczne błędy (wymagana pojemność pamięci itp.);

Błędy inicjalizacji i zakończenia.

W przeciwieństwie do testów białoskrzynkowych, które są wykonywane na wczesnym etapie procesu testowania, testy czarnoskrzynkowe są wykorzystywane na późniejszych etapach testowania. Podczas testowania czarnej skrzynki pomijana jest struktura kontrolna programu. Tutaj nacisk położony jest na obszar informacyjny definicji systemu oprogramowania. Testowanie w tej fazie koncentruje się na przydatności rozwiązania w środowisku produkcyjnym na żywo. Skupiamy się na naprawianiu błędów i określaniu ich wagi oraz przygotowaniu produktu do wydania.

Na etapie testowania rozwiązuje się dwa główne zadania:

Testowanie rozwiązań - plany testów utworzone na etapie planowania oraz rozszerzone i przetestowane w fazie rozwoju są realizowane;

Operacja pilotażowa - wdrożenie rozwiązania w środowisku testowym i testowanie z udziałem przyszłych użytkowników oraz realizacja realnych scenariuszy użytkowania systemu. To zadanie jest wykonywane przed rozpoczęciem fazy wdrażania.

Celem fazy testowania jest zmniejszenie ryzyka, które występuje, gdy rozwiązanie zostanie wprowadzone do użytku komercyjnego.

Aby faza testowania zakończyła się sukcesem, musi nastąpić zmiana podejścia do projektu i przejście dewelopera z tworzenia nowych funkcji na zapewnienie odpowiedniej jakości rozwiązania.

Na tym etapie rozwoju systemu informacyjnego należy przeprowadzić następujące rodzaje testów:

Testowanie podstawowe to testy techniczne niskiego poziomu. Wykonuje go sam programista w trakcie pisania kodu programu. Stosowana jest metoda „białej skrzynki”, duże ryzyko błędów.

Testy użyteczności - testy wysokiego poziomu wykonywane przez testera i przyszłych użytkowników produktu. Stosowana jest metoda „czarnej skrzynki”.

Testy alfa i beta - w kategoriach MSF kod alfa to w zasadzie cały kod źródłowy utworzony w fazie rozwoju modelu procesu MSF, a kod beta to kod, który został przetestowany podczas fazy testowania. Dlatego kod alfa jest testowany podczas fazy rozwoju modelu procesu MSF, a kod beta jest testowany w fazie testowania.

Testowanie zgodności - opracowywane rozwiązanie wymaga zdolności do integracji i współdziałania z istniejącymi systemami i rozwiązaniami programowymi. Ta forma testowania koncentruje się na testowaniu integralności i zdolności opracowanego rozwiązania do interakcji z istniejącymi systemami. W takim przypadku sprawdzona zostanie poprawność działania aplikacji na urządzeniu użytkownika oraz oprogramowanie, z którego korzysta użytkownik.

Testy wydajnościowe - skupione na sprawdzeniu, czy aplikacja spełnia wymagania wydajnościowe i poziom komfortu pod względem szybkości.

Testowanie dokumentacji i systemu pomocy - testowane są wszystkie opracowane dokumenty pomocnicze i systemy pomocy.

Operacja pilotażowa polega na testowaniu rozwiązania w środowisku przemysłowym. Głównym celem operacji pilotażowej jest wykazanie, że rozwiązanie jest zdolne do stabilnej pracy w warunkach przemysłowych i spełnia wymagania biznesowe. Podczas pilotażu rozwiązanie jest testowane w warunkach rzeczywistych. Operacja pilotażowa umożliwia użytkownikom przekazywanie opinii na temat wydajności produktu. Na podstawie tej opinii deweloper eliminuje wszelkie możliwe problemy lub tworzy plan działania na wypadek nieprzewidzianych okoliczności. Ostatecznie operacja pilotażowa pozwala na podjęcie decyzji, czy rozpocząć pełne rozmieszczenie, czy też odłożyć do czasu rozwiązania problemów, które mogłyby zakłócić wdrożenie.

Plan procesu pilotażowego opracowanego systemu informatycznego przedstawiono w tabeli 3.2.

Tabela 3.2 - Plan operacji pilota

działać		Opis
1. Wybór kryteriów sukcesu		Deweloper i osoby badane określają kryteria sukcesu i uzgadniają je
2. Wybór użytkowników i miejsca instalacji		Tworzony jest zespół uczestników testów pilotażowych ze strony użytkowników i programistów. Określana jest lokalizacja procesu pilotażowego.
3. Przygotowanie użytkowników i miejsc instalacji		Szkolenie użytkowników - uczestników testu. Miejsce instalacji jest w przygotowaniu.
4. Wdrażanie wersji rozwojowej		Wersja eksperymentalna jest instalowana i uwzględniana w pracy.
5. Wsparcie i monitorowanie wersji rozwojowej		Monitorowanie pracy użytkowników i systemu, pomoc w obsłudze, zbieranie informacji o pracy systemu
6. Informacje zwrotne od użytkowników i ocena wyników		Użytkownicy wyrażają swoją opinię o działaniu systemu, zwracają uwagę na braki i błędy.
7. Wprowadzanie zmian i uzupełnień	Błędy są poprawiane, wprowadzane są zmiany w projekcie lub procesie. Poprawione wyniki są udostępniane użytkownikom do pracy i oceny.
8. Decyzje o wdrożeniu	Jeżeli wyniki testów pilotażowych zadowalają użytkowników, zapada decyzja o wdrożeniu systemu.

3.2 Technika wdrażania aplikacji

Na tym etapie deweloper (lub zespół) wdraża technologie i komponenty niezbędne do rozwiązania, projekt przechodzi do etapu utrzymania i wsparcia, a klient ostatecznie go zatwierdza. Po wdrożeniu zespół ocenia projekt i przeprowadza ankiety wśród użytkowników w celu określenia ich satysfakcji.

Cele fazy rozmieszczania:

¾  przenieść rozwiązanie do środowiska przemysłowego;

¾  potwierdzenie przez klienta zakończenia projektu.

Wdrożenie komponentów specyficznych dla miejsca składa się z kilku etapów: przygotowania, instalacji, szkolenia i formalnego zatwierdzenia.

Efektem etapu wdrażania systemu są systemy utrzymania i wsparcia, repozytorium dokumentów, w którym znajdują się wszystkie wersje dokumentów i kodu opracowane w ramach projektu.

Aby wdrożyć opracowywany system, sporządzono plan działań, który przedstawiono w tabeli 3.1.

Tabela 3.1 - Plan wdrożenia aplikacji

działać	Opis działania
1. Kopia zapasowa	Kopia zapasowa danych użytkownika jest wykonywana z jego udziałem i zgodą poprzez przenoszenie informacji na nośniki wymienne (CD, DVD)
2. Instalacja podstawowych elementów rozwiązania	Zastosowanie technologii zapewniających działanie rozwiązania. W tym przypadku instalacja składnika Visual FoxPro
3. Instalowanie aplikacji klienckiej	Przeniesienie na komputer użytkownika i zainstalowanie ostatecznej wersji opracowanego IS i bazy danych
4. Szkolenie	Użytkownicy są szkoleni do pracy z systemem, deweloper jest przekonany o poprawności i zrozumieniu działania IP przez klientów
5. Przekazanie klientowi bazy wiedzy projektu	Cała dokumentacja projektowa jest przekazywana klientowi
6. Zamknięcie projektu	Przygotowywany jest raport zamknięcia projektu. Klient podpisuje protokół odbioru.

Do normalnego funkcjonowania AWP wymagany jest system operacyjny Microsoft WindowsXP.

4 Zarządzanie projektami informacyjnymi

4.1 Wybór cyklu rozwoju

Jedną z podstawowych koncepcji metodologii projektowania SI jest koncepcja cyklu życia jej oprogramowania (oprogramowanie cyklu życia). Cykl życia oprogramowania to proces ciągły, który rozpoczyna się od momentu podjęcia decyzji o potrzebie jego stworzenia, a kończy w momencie całkowitego wycofania go z eksploatacji.

Głównym dokumentem regulacyjnym regulującym cykl życia oprogramowania jest międzynarodowa norma ISO / IEC 12207 (ISO - Międzynarodowa Organizacja Normalizacyjna - Międzynarodowa Organizacja Normalizacyjna, IEC - Międzynarodowa Komisja Elektrotechniczna - Międzynarodowa Komisja ds. Elektrotechniki). Określa strukturę cyklu życia, zawierającą procesy, działania i zadania, które muszą być wykonane podczas tworzenia oprogramowania.

ISO / IEC 12207 nie oferuje określonego modelu cyklu życia i metod tworzenia oprogramowania. Model cyklu życia można rozumieć jako strukturę, która określa kolejność wykonywania oraz związek procesów, działań i zadań wykonywanych w trakcie cyklu życia. Model cyklu życia zależy od specyfiki SI i specyfiki warunków, w których jest tworzony i działa.

Obecnie istnieje wiele modeli cyklu życia oprogramowania, ale najbardziej popularne i rozpowszechnione są dwa modele:

Model spiralny (patrz rysunek 4.1);

Model iteracyjny.

Rysunek 4.1 - Spiralny model cyklu życia oprogramowania

Aby stworzyć system informacyjny, tj. Wybrano „Zautomatyzowane stanowisko pracy hurtowni pracowników magazynu”, iteracyjne. Charakterystyczną cechą modelu iteracyjnego jest to, że jest to metoda formalna, składa się z niezależnych faz, wykonywanych sekwencyjnie i podlega częstym przeglądom (rysunek 4.2). Podejście iteracyjne sprawdziło się dobrze w budowaniu IS, dla których już na samym początku rozwoju możliwe jest precyzyjne i wyczerpujące sformułowanie wszystkich wymagań, aby zapewnić programistom swobodę ich implementacji jak najlepiej z technicznego punktu widzenia.

Zalety modelu iteracyjnego:

model jest dobrze znany konsumentom nie będącym oprogramowaniem i użytkownikom końcowym.

Wygoda i łatwość obsługi, bo cała praca jest wykonywana etapami (zgodnie z fazami modelu);

Stabilność wymagań;

Model jest zrozumiały;

Nawet słabo wyszkolony personel (niedoświadczony użytkownik) może kierować się strukturą modelu;

Model radzi sobie ze złożonością w uporządkowany sposób i dobrze sprawdza się w przypadku projektów, które są racjonalnie zrozumiałe;

Model ułatwia wdrożenie ścisłej kontroli zarządzania projektami;

Ułatwia pracę kierownika projektu w zakresie planowania i montażu zespołu programistów.

Rysunek 4.2 - Iteracyjny model cyklu życia oprogramowania

Fazy \u200b\u200bmodelu:

Na etapie analizy określają funkcje, jakie ma pełnić system, wskazują te najbardziej priorytetowe, które wymagają dopracowania w pierwszej kolejności, opisują potrzeby informacyjne;

Na etapie projektowania bardziej szczegółowo rozpatruje się procesy systemu. Model funkcjonalny jest analizowany i, jeśli to konieczne, korygowany. Budowane są prototypy systemów;

System jest rozwijany na etapie wdrożenia;

Na etapie wdrożenia gotowy produkt jest wprowadzany do istniejącego systemu organizacji. Użytkownicy są szkoleni;

Na etapie konserwacji oprogramowanie jest serwisowane (wszelkie dodatki lub zmiany w celu bardziej funkcjonalnego działania produktu).

Wybór modelu cyklu życia oprogramowania jest ważnym krokiem. Dlatego w przypadku projektu wyboru modelu cyklu życia oprogramowania można dokonać podczas stosowania następujących procesów.

Analiza wyróżniających kategorii projektu zamieszczona w tabelach.

Odpowiedz na pytania dla każdej kategorii, podkreślając słowa „tak” i „nie”.

Uporządkuj według ważności kategorie lub pytania związane z każdą kategorią w odniesieniu do projektu, dla którego wybierany jest akceptowalny model.

Zespół deweloperski ... W oparciu o możliwości dobór personelu do zespołu programistów odbywa się jeszcze przed wyborem modelu cyklu życia oprogramowania. Charakterystyka takiego zespołu (patrz Załącznik G, Tabela G.1) odgrywa istotną rolę w procesie wyboru modelu cyklu życia, co oznacza, że \u200b\u200bzespół może w znacznym stopniu pomóc w wyborze modelu cyklu życia produktu oprogramowania, ponieważ odpowiada za pomyślne wdrożenie opracowanego modelu cyklu życia. ...

Zespół użytkowników ... Na początkowych etapach projektu można uzyskać pełny obraz zespołu użytkowników (patrz Załącznik ORAZ Tabela I.1), którzy będą pracować z opracowanym oprogramowaniem, oraz jego przyszłych relacji z zespołem programistycznym w trakcie trwania projektu. Taki pogląd pomaga w wyborze odpowiedniego modelu, ponieważ niektóre modele wymagają zwiększonego udziału użytkownika w procesie tworzenia i studiowania projektu, ponieważ wymagania mogą być nieznacznie zmienione przez użytkownika w trakcie procesu tworzenia, wówczas programista musi znać te zmiany i jak je prezentować w oprogramowaniu.

4.2 Określenie celu i zakresu projektu oprogramowania

Opracowane oprogramowanie do księgowania towarów w magazynie zautomatyzuje proces przyjęcia, strukturyzacji i przechowywania danych o towarach w magazynie, a także uprości proces wystawiania raportów.

Celem projektu oprogramowania będzie - stworzenie i wdrożenie systemu rozliczania towarów. System przeznaczony jest do użytku wewnętrznego przez personel Cleonelly, głównie pracowników magazynu firmy.

Aby określić zakres oprogramowania, zostanie opisane poniżej, co powinno, a czego nie powinno być projektem oprogramowania.

Projekt oprogramowania musi być:

Do użytku wewnętrznego w organizacji;

Projekt wdrożenia dostępu dla wielu użytkowników;

Projekt, który ma możliwość wprowadzania, zmiany i przechowywania informacji o produkcie firmy;

Projekt, który ma możliwość wprowadzania, zmiany i przechowywania informacji o użytkownikach systemu;

Projekt, który ma możliwość wprowadzania, zmiany i przechowywania informacji o klientach i dostawcach organizacji będących przedmiotem zawieranych transakcji;

Projekt, który przeprowadzi tworzenie raportów zewnętrznych.

4.3 Tworzenie struktury dla listy prac krok po kroku

Aby stworzyć unikalny produkt lub usługę (wynik projektu), musisz wykonać określoną sekwencję pracy. Zadaniem planowania projektu jest dokładne oszacowanie czasu i kosztów tych prac. Im dokładniejsza ocena, tym wyższa jakość planu projektu. Aby dokonać trafnej oceny, trzeba dobrze rozumieć zakres projektu, to znaczy wiedzieć, jakiego rodzaju pracę należy wykonać, aby uzyskać jego wynik. Dopiero po sporządzeniu listy prac projektowych szacowany jest czas trwania każdego z nich i alokowane są zasoby niezbędne do ich realizacji. I dopiero wtedy możesz oszacować koszt i harmonogram każdego zadania, a w wyniku dodania, całkowity koszt i czas trwania projektu. Dlatego określenie zakresu prac jest pierwszym krokiem w planowaniu projektu. Określenie zakresu prac projektowych rozpoczyna się od określenia etapów (lub faz) projektu. Przykładowo w projekcie stworzenia systemu „Księgowanie towarów na stanie” można wyróżnić następujące fazy:

Opracowywanie wymagań oprogramowania;

Projekt systemu informacyjnego;

Wdrożenie i certyfikacja systemu informatycznego;

Implementacja systemu.

Po ustaleniu składu faz i ich wyników należy ustalić kolejność tych faz względem siebie oraz terminy ich realizacji. Następnie należy ustalić, z jakich prac składają się poszczególne etapy, w jakiej kolejności prace te są wykonywane iw jakich terminach należy je dotrzymać po ich zakończeniu.

Lista prac krok po kroku (rysunek 4.3) została zaprojektowana przy użyciu oprogramowania, takiego jak MS Project 2003.

Rysunek 4.3 - Lista prac krok po kroku

4.4 Szacowanie czasu trwania i kosztu rozwoju oprogramowania

Oszacowanie czasu trwania. Wyznacza się go po zbudowaniu listy prac krok po kroku (rysunek 4.3, punkt 4.3). Ten szacowany czas trwania można zobaczyć na wykresie Gantta (dodatek K).

Diagramy to graficzny sposób wyświetlania informacji zawartych w pliku projektu. Z wykresów można uzyskać wizualne wyobrażenie o kolejności zadań, ich względnym czasie trwania i czasie trwania projektu jako całości.

Wykres Gantta jest jednym z najpopularniejszych sposobów graficznego przedstawienia planu projektu i jest używany w wielu programach do zarządzania projektami.

W programie MS Project wykres Gantta jest głównym narzędziem wizualizacji planu projektu. Ten wykres to wykres z poziomą osią czasu i pionową listą zadań. W tym przypadku długość segmentów oznaczających zadania jest proporcjonalna do czasu trwania zadań.

Na wykresie Gantta obok pasków mogą być wyświetlane dodatkowe informacje (obok zadań wyświetlane są nazwy zaangażowanych w nie zasobów oraz ich ładowanie po wykonaniu zadania).

Oszacowanie kosztów

Projekt składa się z zadania , czyli działania mające na celu osiągnięcie określonego rezultatu. Aby zadanie zostało wykonane, zasoby .

Ważną właściwością zasobów jest koszt (Koszt) ich wykorzystania w projekcie. Istnieją dwa rodzaje kosztów zasobów w MS Project: stawka czasowa i koszt użycia.

Stawka czasowa (Stawka) jest wyrażona w koszcie korzystania z zasobu na jednostkę czasu, na przykład 100 rubli za godzinę lub 1000 rubli dziennie. W takim przypadku kosztem udziału zasobu w projekcie będzie czas, w którym zasób pracuje w projekcie, pomnożony przez stawkę godzinową.

W tym przypadku posłużono się wskaźnikiem czasu (rysunek 4.4) Całkowity koszt wykorzystania zasobów przedstawiono na rysunku 4.5.

Rysunek 4.4 - Wskaźnik czasu wykorzystania zasobów

Na tej figurze widać, że programista systemu otrzymuje 50 rubli za godzinę podczas wykonywania projektu; analityk biznesowy otrzymuje 45 rubli za godzinę, tester 38 rubli za godzinę. Stawki za nadgodziny nie są wliczone.

Rysunek 4.5 - Całkowite koszty wykorzystania zasobów projektu

4.5 Alokacja zasobów projektu

Fragment podziału zasobów dla systemu „Inventory Accounting” przedstawiono na rysunku 4.6

Rysunek 4.6 - Fragment dystrybucji zasobów projektu

Do każdej pracy wykonanej w projekcie skojarzony jest zasób, który wykona tę pracę. Rysunek przedstawia całkowitą ilość pracy dla każdego zasobu i określoną liczbę godzin spędzonych w określonym dniu.

4.6 Ocena efektywności ekonomicznej projektu

Obliczenie efektywności ekonomicznej projektu jest ważnym krokiem. To tutaj zostanie obliczona ekonomiczna efektywność projektu. Kalkulacja ta pokaże, jak opłacalny jest projekt lub projekt całkowicie nieopłacalny. Przy obliczaniu efektywności ekonomicznej projektu konieczne będzie obliczenie okresu zwrotu projektu. Okres zwrotu będzie wskazywał okres, w którym projekt się zwróci.

Dane wejściowe.

Dodatkowy zysk z realizacji projektu (DP) \u003d 38 000 rubli. Dodatkowy zysk przewidzieli eksperci firmy.

Inwestycja początkowa (KI) \u003d 39396,47 rubli. Inwestycje początkowe odpowiadają całkowitym kosztom wykorzystania zasobów projektu (rysunek 4.5, punkt 4.6)

Stopa dyskontowa (i) \u003d 12%.

Okres, na jaki projekt jest projektowany (n) \u003d 2 lata.

Dodatkowy zysk z realizacji projektu (DP) \u003d 38 000 rubli.

Roczne koszty realizacji projektu (Z 1) \u003d 15 000 rubli.

Roczne koszty realizacji projektu (Z 2) \u003d 10 000 rubli.

Roczne wpływy gotówkowe (R 1) \u003d 23000 rubli.

Roczne wpływy gotówkowe (R 2) \u003d 28000 rubli.

Przy ocenie projektów inwestycyjnych stosuje się metodę obliczania wartości bieżącej netto, która przewiduje dyskontowanie przepływów pieniężnych: wszystkie przychody i koszty są sprowadzane do jednego punktu w czasie.

Centralnym wskaźnikiem w rozważanej metodzie jest NPV (wartość bieżąca netto) - bieżąca wartość przepływów pieniężnych. Jest to uogólniony wynik końcowy działalności inwestycyjnej w wartościach bezwzględnych.

Ważną kwestią jest wybór stopy dyskontowej, która powinna odzwierciedlać oczekiwaną średnią stopę kredytową na rynku finansowym.

Wartość bieżącą netto (NPV) oblicza się według wzoru 4.2

(4.2)

R k - roczne wpływy pieniężne za n lat.

k - liczba lat, przez które projekt jest projektowany.

IC - inwestycja początkowa.

i - stopa dyskontowa.

Zgodnie z obliczeniami tego wzoru NPV \u003d 3460,67 RUB

Wartość bieżąca netto jest bezwzględnym wzrostem, ponieważ szacuje, w jakim stopniu obecny dochód pokrywa się z obecnymi kosztami. Ponieważ NPV\u003e 0, projekt powinien zostać zaakceptowany.

Zwrot z inwestycji (ROI) jest obliczany według wzoru 4.3

(4.3)

Obliczony (ROI) \u003d 108,78%

Tabela 4.1  Pomocnicza tabela do obliczenia okresu zwrotu projektu

= 1,84

Okres zwrotu n ok \u003d 1,84 roku (1 rok i 11 miesięcy)

Ponieważ ROI \u003d\u003e 100% (czyli \u003d 108,78%), projekt jest uważany za opłacalny.

(4.4)

Zatem wskaźnik rentowności wynosi (PI) \u003d 1,2

Elementy zapewniające działanie SI w jakimkolwiek celu są wymienione w definicji. Niektóre z nich - środki, metody i personel - zapewniają działanie SI, inne - przechowywanie, przetwarzanie i wydawanie informacji - wskazują cechy funkcjonalne, tj. określić, z jakich procesów informacyjnych składa się funkcjonowanie SI. Dlatego strukturę SI rozpatruje się na dwa różne sposoby: strukturę funkcjonalną i strukturę SI jako zbiór podsystemów wspierających.

Zgodnie z definicją elementami funkcjonalnymi SI są następujące grupy (bloki) procesów:

wprowadzanie informacji ze źródeł zewnętrznych lub wewnętrznych;

przetwarzanie informacji wejściowych i przedstawianie ich w wygodnej formie;

wyjście informacji do prezentacji konsumentom lub przeniesienia do innego IS;

informacja zwrotna to informacja przetwarzana przez ludzi w danej organizacji w celu skorygowania wprowadzonych informacji.

Funkcjonalna struktura systemy informacyjne przedstawiono w postaci schematu blokowego (rys. 1), na którym każdy element systemu jest przedstawiony w postaci bloku (na rys. - prostokąt), a łącza i ich kierunki zaznaczono strzałkami.

Poszczególne części (bloki systemowe) nazywane są podsystemami.

W każdym konkretnym przypadku zestaw i wzajemne powiązania podsystemów funkcjonalnych zależą od obszaru tematycznego i specyfiki przedsiębiorstwa, którego działalność zapewnia system informatyczny.

Strukturę SI można również przedstawić jako zespół podsystemów wspierających (rys. 2).

Ryc.1. Uogólniony funkcjonalny schemat blokowy IC.

Jednak w przypadku AIS, które różnią się charakterem i typami przetwarzania informacji, schemat funkcjonalny różni się zestawem podsystemów przetwarzania. Na przykład AIPS (biblioteka, muzeum, bibliografia itp.) Generuje dane wejściowe, systematyzuje, przechowuje, wyszukuje i dostarcza informacje na żądanie użytkownika bez skomplikowanych przekształceń danych. Systemy informacyjno-decyzyjne: ASOD, ACS, DSS - przetwarzają informacje z bazy danych według określonego algorytmu, różnią się jednak także składem podsystemów przetwarzania informacji. System CAD specjalizujący się w automatyzacji projektowania ma w swojej strukturze specjalne podsystemy: dokumentację techniczną, tworzenie zadań, symulację, obliczenia, a niektóre mogą również posiadać system ekspertowy (patrz schemat blokowy na rys. 2).

Ryc.2. Schemat blokowy CAD

Rozważ inny typ struktury SI: jako zespół podsystemów wspierających (rys. 3).

Strukturę systemu informacyjnego można postrzegać jako zbiór podsystemów, niezależnie od zakresu. Podsystem to część systemu, wybrana według jakiegoś atrybutu. W tym przypadku mówimy o cechach strukturalnych klasyfikacji, a podsystemy nazywane są dostarczaniem.

Zatem struktura dowolnego systemu informatycznego może być reprezentowana przez zbiór podsystemów wspierających.

Ryc.3. Struktura SI według rodzaju podsystemów wspierających.

Wśród podsystemów wspierających zwykle wyróżnia się wsparcie informacyjne, techniczne, matematyczne, programowe, organizacyjne i prawne.

Wsparcie informacyjne - zbiór zbiorów danych informacyjnych, ujednolicony system klasyfikacji i kodowania informacji, ujednolicone systemy dokumentacji, schematy przepływów informacji w organizacji, a także metodologia budowy baz danych. Zadaniem podsystemu wsparcia informacji jest terminowe tworzenie i dostarczanie wiarygodnych informacji do podejmowania decyzji zarządczych.

Zunifikowane systemy dokumentacji powstają na poziomie stanowym, republikańskim, sektorowym i regionalnym. Głównym celem jest zapewnienie porównywalności wskaźników różnych sfer produkcji społecznej. Normy zostały opracowane tam, gdzie ustalono wymagania:

do ujednoliconych systemów dokumentacji;

do ujednoliconych form dokumentów różnych szczebli zarządzania;

do składu i struktury szczegółów i wskaźników;

do procedury wdrażania, utrzymywania i rejestracji ujednoliconych formularzy dokumentów.

Pomimo istnienia ujednoliconego systemu dokumentacji, badanie większości organizacji ujawnia cały zestaw typowych niedociągnięć:

wyjątkowo duża ilość dokumentów do ręcznego przetwarzania;

te same wskaźniki są często powielane w różnych dokumentach;

praca z dużą liczbą dokumentów odwraca uwagę specjalistów od rozwiązywania doraźnych problemów;

istnieją wskaźniki, które są tworzone, ale nie są używane itp.

Eliminacja tych niedociągnięć jest jednym z zadań stojących przed stworzeniem wsparcia informacyjnego.

Diagramy przepływu informacji odzwierciedlają drogi przepływu informacji, ich objętości, miejsca pochodzenia informacji pierwotnych i wykorzystanie informacji wynikowych. Analizując strukturę takich schematów, można opracować działania usprawniające cały system zarządzania.

Budowa i szczegółowa analiza diagramów przepływu informacji, pozwalająca na identyfikację tras i wolumenów informacji, powielanie wskaźników i procesy ich przetwarzania, zapewnia:

eliminacja zduplikowanych i niewykorzystanych informacji;

klasyfikacja i racjonalna prezentacja informacji.

Metodyka budowy baz danych w oparciu o teoretyczne podstawy ich konstrukcji.

Podstawowe pojęcia metodologii:

jasne zrozumienie celów, zadań, funkcji całego systemu zarządzania organizacją;

identyfikacja przepływu informacji od momentu ich powstania do wykorzystania na różnych poziomach zarządzania, przedstawiana do analizy w postaci schematów przepływu informacji;

usprawnienie systemu zarządzania dokumentami;

dostępność i stosowanie systemu klasyfikacji i kodowania;

znajomość metodologii tworzenia pojęciowych modeli informacyjno-logicznych, które odzwierciedlają związek informacji;

tworzenie tablic informacji na nośnikach komputerowych, co wymaga nowoczesnego wsparcia technicznego.

Ta koncepcja jest praktycznie realizowana w dwóch etapach.

I etap - badanie wszystkich pionów funkcjonalnych firmy w celu:

rozumieć specyfikę i strukturę swojej działalności;

zbudować diagram przepływu informacji;

przeanalizować istniejący system zarządzania dokumentami;

definiowanie obiektów informacyjnych i odpowiadającej im kompozycji atrybutów (parametrów, cech) opisujących ich właściwości i przeznaczenie.

II etap - budowa koncepcyjnego informacyjno-logicznego modelu danych na podstawie wyników badania I etapu. W tym modelu wszystkie połączenia między obiektami i ich atrybutami muszą zostać ustanowione i zoptymalizowane. Model informacyjno-logiczny jest fundamentem, na którym zostanie utworzona baza danych.

Pomoc techniczna - zestaw środków technicznych przeznaczonych do działania systemu informatycznego oraz odpowiednią dokumentację tych środków i procesów technologicznych

Kompleks środków technicznych składa się z:

komputery dowolnego modelu;

urządzenia do zbierania, gromadzenia, przetwarzania, przesyłania i wyprowadzania informacji;

urządzenia do transmisji danych i linie komunikacyjne;

sprzęt biurowy i urządzenia do automatycznego wyszukiwania informacji;

materiały eksploatacyjne itp.

Dokumentacja formalizuje wstępny dobór środków technicznych, organizację ich działania, proces technologiczny przetwarzania danych, wyposażenie technologiczne. Dokumentację można z grubsza podzielić na trzy grupy:

ogólnosystemowe, w tym stanowe i branżowe standardy pomocy technicznej;

specjalistyczne, zawierające zestaw metod dla wszystkich etapów rozwoju wsparcia technicznego;

odniesienie normatywne, używane podczas wykonywania obliczeń dla wsparcia technicznego.

Do tej pory rozwinęły się dwie główne formy organizacji wsparcia technicznego (formy wykorzystania środków technicznych): scentralizowana oraz częściowo lub całkowicie zdecentralizowana.

Scentralizowane wsparcie techniczne opiera się na wykorzystaniu dużych komputerów i centrów obliczeniowych w systemie informatycznym. Ta forma organizacji ułatwia zarządzanie i wdrażanie normalizacji, ale ogranicza odpowiedzialność i inicjatywę personelu.

Decentralizacja środków technicznych polega na wdrażaniu podsystemów funkcjonalnych na komputerach osobistych bezpośrednio na stanowiskach pracy. W takim przypadku od pracowników wymagana jest większa odpowiedzialność osobista, kierownictwu trudniej jest wdrożyć standaryzację.

Obecnie bardziej rozpowszechnione jest podejście częściowo zdecentralizowane - organizacja wsparcia technicznego w oparciu o rozproszone sieci składające się z komputerów osobistych i mainframe do przechowywania baz danych wspólnych dla dowolnych podsystemów funkcjonalnych.

Matematyka i oprogramowanie - zbiór metod matematycznych, modeli, algorytmów i programów do realizacji celów i założeń systemu informatycznego, a także normalnego funkcjonowania zespołu środków technicznych.

Do funduszy oprogramowanie odnosić się:

narzędzia do modelowania procesów zarządzania;

typowe zadania zarządcze;

metody programowania matematycznego, statystyka matematyczna, teoria kolejek itp.

Część oprogramowanie obejmuje oprogramowanie systemowe i specjalne, a także dokumentację techniczną.

DO oprogramowanie systemowe zawiera zestaw programów skierowanych do użytkowników i zaprojektowanych do rozwiązywania typowych zadań przetwarzania informacji. Służą do rozszerzania funkcjonalności komputerów, kontroli i zarządzania procesem przetwarzania danych.

Specjalne oprogramowanie to zestaw programów opracowanych podczas tworzenia określonego systemu informacyjnego. Obejmuje stosowane pakiety oprogramowania (PPP), które implementują opracowane modele o różnym stopniu adekwatności, odzwierciedlające funkcjonowanie rzeczywistego obiektu.

Dokumentacja techniczna do wykonania oprogramowania powinna zawierać opis zadań, zadanie algorytmizacji, model ekonomiczno-matematyczny problemu, przykłady testowe.

Wsparcie organizacyjne To zbiór metod i środków, które regulują interakcję pracowników ze środkami technicznymi i między sobą w rozwoju i działaniu SI.

Wsparcie organizacyjne realizuje następujące funkcje:

analiza istniejącego systemu zarządzania organizacją, w której będzie używany IS oraz identyfikacja zadań do zautomatyzowania;

przygotowanie zadań do rozwiązania na komputerze, w tym specyfikacji technicznych projektu SI oraz studium wykonalności jego skuteczności;

opracowywanie decyzji zarządczych dotyczących składu i struktury organizacji, metodologii rozwiązywania problemów mających na celu poprawę efektywności systemu zarządzania.

Wsparcie organizacyjne tworzone jest na podstawie wyników ankiety przedprojektowej na I etapie budowy bazy danych.

Wsparcie prawne - zbiór norm prawnych określających tworzenie, stan prawny i działanie systemów informatycznych, regulujących procedurę pozyskiwania, przetwarzania i wykorzystywania informacji.

Głównym celem wsparcia prawnego jest wzmocnienie praworządności. Ramy prawne obejmują ustawy, dekrety, decyzje organów państwowych, zarządzenia, instrukcje i inne dokumenty normatywne ministerstw, departamentów, organizacji, władz lokalnych. W obsłudze prawnej można wyróżnić część ogólną regulującą funkcjonowanie dowolnego systemu informatycznego oraz część lokalną, regulującą funkcjonowanie konkretnego systemu.

Obsługa prawna etapów tworzenia systemu informatycznego obejmuje regulacje dotyczące stosunków umownych pomiędzy deweloperem a klientem oraz regulacje prawne odstępstw od umowy.

Obsługa prawna etapów funkcjonowania systemu informatycznego obejmuje:

stan systemu informacyjnego;

prawa, obowiązki i obowiązki personelu;

procedura tworzenia i wykorzystywania informacji itp.

Ten zestaw podsystemów jest ogólny dla prawie wszystkich typów AIS. Jednak struktura i złożoność podsystemów wspomagających zależy od rodzaju AIS, zakresu zastosowania i innych czynników. Tak więc podsystem oprogramowania odbywa się w AIS pierwotnego rozwoju oprogramowania - w AIS ze standardowym oprogramowaniem jest nieobecny. Podsystem obsługi prawnej może być nieobecny w AIS dla celów wewnątrzzakładowych - w tym przypadku można ograniczyć się do podsystemu obsługi organizacyjnej, w którym między innymi rozwiązuje się kwestie obsługi prawnej; Samoczynne AIS, na przykład systemy usług informacyjnych, mogą mieć podsystem wsparcia prawnego. AIS, które posiadają faktyczną bazę danych, mają jedynie podsystem obsługi informacyjnej, w którym może być konieczne rozwiązanie pewnych problemów językowych. Dokumentalne AIPS posiadają rozbudowany podsystem obsługi językowej, gdyż systemy te rozwiązują złożone problemy związane z zapewnieniem semantycznej zgodności żądań użytkowników z treścią wydawanych dokumentów. A to z reguły nie tylko moduły oprogramowania do analizy morfologicznej, ale także zestaw słowników i zasad ich utrzymania.

Cele tworzenia i wdrażania własności intelektualnej.

Czego można się spodziewać po wdrożeniu systemów informatycznych?

Wdrożenie systemów informacyjnych może przyczynić się do:

1. zwolnienie pracowników z rutynowej pracy i jej przyspieszenie w wyniku automatyzacji;

2. zastąpienie papierowych nośników danych dyskami lub taśmami magnetycznymi, co prowadzi do zmniejszenia ilości dokumentów na papierze, a tym samym możliwości bardziej racjonalnej organizacji przetwarzania informacji na komputerze;

3. doskonalenie struktury przepływu informacji i systemu zarządzania dokumentami w przedsiębiorstwie ze względu na efekt spójności: jednorazowe wprowadzanie danych - wielokrotne i uniwersalne zastosowanie ”;

4. uzyskanie bardziej racjonalnych możliwości rozwiązywania problemów zarządczych (poprzez wprowadzenie metod matematycznych i inteligentnych systemów itp.):

znajdowanie nowych nisz rynkowych;

optymalizacja kosztów produkcji produktów i / lub usług;

optymalizacja relacji z odbiorcami i dostawcami.

Etapy rozwoju systemów informatycznych

Historia rozwoju własności intelektualnej podzielona jest na etapy (tab. 2), odpowiadające w przybliżeniu przyjętej numeracji celów - zmienia się podejście do korzystania z własności intelektualnej.

Tabela 2. Etapy rozwoju własności intelektualnej.

Okres czasu	Koncepcja wykorzystania informacji	Rodzaje systemów informacyjnych	Przeznaczenie
1950 - 1960	Obieg papierowy dokumentów rozliczeniowych	Systemy informacyjne do przetwarzania dokumentów rozliczeniowych na elektromechanicznych maszynach księgowych	Zwiększenie szybkości przetwarzania dokumentów Uproszczone przetwarzanie faktur i płac
1960 - 1970	Podstawowa pomoc w przygotowaniu raportów	Systemy informacji zarządczej dla informacji produkcyjnych	Przyspieszenie procesu raportowania
1970 - 1980	Zarządzanie zarządzaniem wdrożeniem (sprzedażą)	Systemy Wspomagania Decyzji Systemy dla wyższego kierownictwa	Wybór najbardziej racjonalnego rozwiązania
1980 - 2000	Informacja to strategiczny zasób zapewniający przewagę konkurencyjną	Strategiczne systemy informacyjne Zautomatyzowane biura	Solidne przetrwanie i dobrobyt

Pierwsze systemy informacyjne pojawiły się w połowie ubiegłego wieku. W latach pięćdziesiątych XX wieku były przeznaczone do obsługi faktur i naliczania wynagrodzeń oraz zostały wdrożone na elektromechanicznych maszynach księgowych. Doprowadziło to do pewnego zmniejszenia kosztów i czasu przygotowania dokumentów papierowych.

60s charakteryzują się zmianą postaw wobec systemów informacyjnych. Uzyskane od nich informacje zaczęto na wiele sposobów wykorzystywać do okresowych raportów. W tym dniu organizacje potrzebowały sprzętu komputerowego ogólnego przeznaczenia, mogącego pełnić różne funkcje, a nie tylko przetwarzać faktury i obliczać wynagrodzenia, jak to było wcześniej.

W latach 70-tych - wczesnych 80-tych. Systemy informacyjne zaczynają być szeroko stosowane jako środek kontroli zarządczej wspierający i przyspieszający proces podejmowania decyzji.

Pod koniec lat 80-tych. koncepcja korzystania z systemów informatycznych ponownie się zmienia. Stają się strategicznym źródłem informacji i są wykorzystywane na wszystkich poziomach organizacji o dowolnym profilu. Systemy informacyjne z tego okresu, dostarczające niezbędnych informacji na czas, pomagają organizacji osiągnąć sukces w jej działalności, tworzyć nowe produkty i usługi, znajdować nowe rynki zbytu, dostarczać godnych partnerów, organizować wypuszczanie produktów po niskiej cenie i wiele więcej.

Współczesne rozumienie systemu informatycznego zakłada wykorzystanie komputera osobistego jako głównego technicznego środka przetwarzania informacji. W dużych organizacjach, wraz z komputerem osobistym, podstawa techniczna systemu informatycznego może obejmować komputer mainframe lub superkomputer. Ponadto techniczne wdrożenie systemu informatycznego samo w sobie nic nie znaczy, jeśli nie weźmie się pod uwagę roli osoby, dla której informacja jest przeznaczona i bez której nie można jej odebrać i przedstawić.

Stacje robocze do zautomatyzowania

Wymagania dotyczące wydajności

Lista wygenerowanych raportów

4.4.2. Wymagania dotyczące systemu planowania i zarządzania produkcją

System informacyjny musi zapewniać planowanie zasobów przedsiębiorstwa i zarządzanie produkcją zamówień.

Wymagania dotyczące funkcji IS:

1. Zarządzanie konfiguracją gotowych produktów (FP):

Utrzymywanie informacji regulacyjnych i referencyjnych dotyczących składu GP z możliwością wskazania okresu obowiązywania specyfikacji oraz z możliwością bycia w produkcji GP z kilkoma różnymi specyfikacjami;

Utrzymywanie informacji normatywnych i referencyjnych dotyczących technologii wytwarzania produktów wchodzących w skład GP z możliwością wskazania okresu obowiązywania technologii oraz z możliwością bycia w produkcji GP z kilkoma różnymi technologiami;

2. Zarządzanie sprzedażą:

Przeglądanie historii relacji z klientami;

Rejestracja / korekta wniosku klienta ze wskazaniem listy SOE, ilości, daty wysyłki, ceny sprzedaży i ewentualnych dodatkowych warunków;

Zobacz aktualne wskaźniki ekonomiczne (kosztorysy) zamówionego przedsiębiorstwa państwowego;

3. Planowanie produkcji:

Stworzenie harmonogramu dostępności sprzętu ze wskazaniem liczby dostępnych standardowych godzin na każdy dzień planowanego okresu;

Stworzenie planu produkcji ze wskazaniem wytwarzanego produktu, jego ilości, używanego wyposażenia, podziału na każdy dzień okresu planowania;

Stworzenie planu wymagań produkcyjnych dla materiałów i komponentów;

Kontrola i zarządzanie załadunkiem sprzętu zgodnie z utworzonym planem produkcji;

Dokonywanie korekt planu produkcyjnego w trakcie jego wykonywania;

Analiza planowo-faktyczna planu produkcji;

4. Zarządzanie produkcją:

Tworzenie zadań zmianowych (zamówień) do wytwarzania produktów;

Przypisywanie / ponowne przypisywanie do zamówień wykonawców i ustalanie realizacji zamówień ze wskazaniem ilości wytworzonych produktów, ilości produktów wadliwych oraz przyczyn zawarcia małżeństwa;

Zarządzanie magazynowaniem i przemieszczaniem pozycji zapasów (TMC) w produkcji;

5. Zarządzanie dostawami:

Tworzenie zamówienia na podstawie planu zapotrzebowania na materiały i komponenty, ze wskazaniem dostawcy, nazewnictwa towarów i materiałów, ilości i czasu dostawy;

Tworzenie zamówień na podstawie jednorazowych zamówień na towary i materiały z oddziałów;

Kontrolowanie i śledzenie procesu realizacji zamówień;

Operacyjna kontrola pozostałości;

Analiza planowo-faktyczna dostaw;

6. Zarządzanie kosztami:

Ustalenie planowanego (standardowego) kosztu SOE;

Ustalenie rzeczywistych kosztów produkcji;

Obliczenie rzeczywistego kosztu przedsiębiorstwa państwowego;

Analiza kosztów rzeczywistych.

Wymagania dotyczące obliczenia standardowego kosztu zamówienia

Koszt standardowy produktu i całego zamówienia liczony jest następującą metodą:

1. Bezpośredni materiałowy składnik kosztu standardowego produktu jest tworzony na podstawie informacji o standardowym składzie tego produktu (specyfikacji) oraz ustalonych cenach księgowych dla pozycji magazynowych objętych niniejszą specyfikacją. W specyfikacji dozwolone jest użycie kilku pozycji kosztów materiałowych.

2. Wysokość wynagrodzenia bezpośredniego obliczana jest na podstawie standardowego składu operacyjnego produktu. Ustala się: standardowy czas trwania każdej operacji, zawód pracownika wymagany do tej operacji, a także stopień pracownika. Ponadto system wprowadza pieniężne stawki godzinowe dla zawodów pracowników i ich kategorii.

3. Standardową wartość kosztów pośrednich oblicza się jako procent określonej podstawy (kwota kosztów bezpośrednich dla określonej pozycji).

Aby przeprowadzić to obliczenie, w systemie informacyjnym muszą być dostępne następujące dane:

1. Specyfikację sposobu wytwarzania produktu (a także specyfikację wytwarzania wszystkich półproduktów własnej produkcji wchodzących w skład tego produktu);

2. Technologia wytwarzania produktu i zawartych w nim półfabrykatów: jakie operacje należy wykonać iw jakim czasie. Dodatkowo dla każdej operacji określa się zawód i kategorię pracownika, które są niezbędne do jej realizacji (do wydania tego konkretnego produktu);

3. Protokół cen księgowych dla używanych towarów i materiałów;

4. Stawki pieniężne godzin standardowych dla zawodów i rang.

Wymagania dotyczące obliczenia rzeczywistego kosztu zamówienia

Rzeczywisty koszt produktu i całego zamówienia liczony jest następującą metodą:

1. Bezpośrednie koszty materiałowe związane z wydaniem produktu są obliczane na podstawie rzeczywistych danych o zużyciu materiałów przez sklep do redystrybucji produkcji. W takim przypadku w pierwszej kolejności obliczany jest koszt wszystkich półproduktów zawartych w tym produkcie. Całkowita ocena dokonywana jest zgodnie z metodologią przyjętą w polityce rachunkowości przedsiębiorstwa.

2. Płace pracowników produkcji bezpośredniej obliczane są na podstawie danych o zamknięciu zamówień sklepowych. Jeśli nie prowadzi się księgowania zleceń w SI, wynagrodzenia odnoszone są do kosztów bezpośrednich podlegających dystrybucji, tj. rozdzielane między wytworzone produkty według określonej bazy.

3. Amortyzacja sprzętu do produkcji bezpośredniej jest ujęta w kosztach bezpośrednich, jeśli dla każdej redystrybucji wskazany jest sprzęt (obrabiarka) użyty w tej redystrybucji.

4. Koszty bezpośrednie do alokacji:

Podstawowe materiały zużywane rzadziej niż przy każdej redystrybucji (na przykład chemikalia, których wskaźnik na jednostkę produkcji jest tak mały, że nie ma sensu uwzględniać ich alternatywnego zużycia nawet przy takim tempie);

Płace pracowników w przypadku braku informacji o ich podziale według obrotów;

Amortyzacja bezpośredniego wyposażenia, jeśli dostępna jest tylko jego całkowita miesięczna kwota, bez podziału na redystrybucję.

Koszty te są alokowane do wytwarzanych towarów zgodnie z wybraną bazą dystrybucji (np. Proporcjonalnie do bezpośrednich kosztów materiałowych).

1. Ogólne koszty produkcji (konto 25 BU): rozdzielane na wytworzone produkty proporcjonalnie do wybranej bazy dystrybucyjnej. Udział tych wydatków może, ale nie musi pozostać w produkcji niezakończonej, zgodnie z polityką rachunkowości przyjętą w przedsiębiorstwie.

2. Ogólne koszty operacyjne i koszty sprzedaży (konta 26 i 44) są ujmowane jako koszty bieżącego okresu i dotyczą kosztów sprzedaży. Rozkład tych kosztów na koszt gotowych produktów można zobaczyć na specjalnym raporcie.

Wymagania dotyczące wydajności systemu informacyjnego

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

Wymagania dotyczące niezawodności

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

Wymagania dotyczące zapewnienia niezawodnego (stabilnego) funkcjonowania systemu informacyjnego

Niezawodne (stabilne) funkcjonowanie Systemu Informatycznego musi być zapewnione poprzez wdrożenie przez Klienta zestawu środków organizacyjno-technicznych, których wykaz podano poniżej:

1. Organizacja nieprzerwanego zasilania urządzeń technicznych;

2. Korzystanie z licencjonowanego oprogramowania;

3. Regularne wdrażanie zaleceń Ministerstwa Pracy i Rozwoju Społecznego Federacji Rosyjskiej, zawartych w Dekrecie z dnia 23 lipca 1998 r. „O zatwierdzeniu międzybranżowych standardów czasowych dla prac przy konserwacji komputerów osobistych i sprzętu biurowego oraz wsparcia oprogramowania”;

4. Regularne spełnianie wymagań GOST 51188-98. "Ochrona danych. Testowanie oprogramowania na obecność wirusów komputerowych ”;

5. Regularne tworzenie kopii zapasowych baz danych Systemu Informacyjnego przy pomocy samego Systemu Informatycznego lub za pomocą używanego systemu zarządzania bazami danych.

Figa. 6.2.

(System informacji przedsiębiorstwa)

Outsourcing korporacyjnych systemów informatycznych

Outsourcing funkcji produkcyjnych i procesów biznesowych w oparciu o korporacyjne systemy informacyjne pozwala na wykorzystanie najnowszych osiągnięć i „najlepszych praktyk” nowoczesnego zarządzania. Wdrażanie korporacyjnych systemów informatycznych jest podstawą przebudowy procesów biznesowych (Proces biznesowy...
(Outsourcing i outstaffing: zaawansowane technologie zarządzania)

Wzorce integracji korporacyjnych systemów informatycznych

Wzorce integracji systemów informacyjnych reprezentują górny poziom klasyfikacji wzorców projektowych. Podobnie jak we wzorcach niższych poziomów klasyfikacji, wśród wzorców integracji wyróżnia się grupę wzorców strukturalnych. Wzorce strukturalne opisują główne komponenty jednego zintegrowanego ...
(Wprowadzenie do architektury oprogramowania)

ZADANIA FUNKCJONALNE SYSTEMU INFORMACYJNEGO PRZEDSIĘBIORSTWA I PODSTAWOWE MODUŁY NOWOCZESNYCH SYSTEMÓW INFORMACYJNYCH PRZEDSIĘBIORSTWA. INTEGRACJA MODUŁÓW

Sensowne znaczenie pojęcia modułu zakłada porównanie podsystemów funkcjonalnych, zadań funkcjonalnych z podejściem funkcjonalnym zadaniowym z głównymi modułami nowoczesnego Figa. 6.2. Porównanie zadań funkcjonalnych z głównymi modułami nowoczesnych systemów informatycznych ICISP przedsiębiorstwa, ...
(System informacji przedsiębiorstwa)

KONCEPCJA, HISTORIA ROZWOJU I KLASYFIKACJA SYSTEMÓW INFORMACYJNYCH PRZEDSIĘBIORSTWA. ZINTEGROWANE SYSTEMY INFORMACJI KORPORACYJNEJ PRZEDSIĘBIORSTWA

Koncepcja i klasyfikacja systemów informacyjnych zmieniają się w trakcie ich historycznego rozwoju. Jednak cel pozostaje niezmienny i wiąże się z osiągnięciem efektywności zarządzania przedsiębiorstwem. Efektywność zarządzania przedsiębiorstwem zależy od interakcji wielu czynników, między innymi: filozoficznych, historycznych, ...
(System informacji przedsiębiorstwa)

CECHY NOWOCZESNYCH TECHNOLOGII INFORMATYCZNYCH W SYSTEMACH INFORMACYJNYCH PRZEDSIĘBIORSTWA

NOWOCZESNE TECHNOLOGIE ORGANIZACJI WPROWADZANIA DANYCH DO KORPORACYJNYCH SYSTEMÓW INFORMACYJNYCH Informacje o transakcjach handlowych należy terminowo wprowadzać do operacyjnej bazy danych z wszelkich źródeł jej pochodzenia. To skutecznie zorganizuje dalsze przetwarzanie danych w informacjach ...
(System informacji przedsiębiorstwa)

Wzajemne powiązania podsystemów informacyjnych przedsiębiorstwa

Jak się masz systemy informacyjne w przedsiębiorstwie? Zwykłą ścieżką dla średniej wielkości rosyjskiej firmy jest rozpoczęcie wdrażania technologii informatycznych poprzez automatyzację pracy działu księgowości, działu HR i przepływu pracy. Dane z tych systemów są najbardziej sformalizowane, procesy łatwo można zautomatyzować. Szeroko rozpowszechnione pakiety „1C: Księgowość”, „Szef: Oficer kadrowy”, „LanDocs”, „LanStaff”, „Wynagrodzenie” itp. Pozwalają na rozbudowę dowolnych aplikacji, a tym samym na ich integrację z ogólnym systemem informacyjnym przedsiębiorstwa. Figa. 7.1 pokazuje, w jaki sposób moduły systemu informatycznego firmy są ze sobą powiązane. Moduł TPS obsługuje główne procesy produkcyjne i wspomagające oraz jest zwykle głównym źródłem dla innych modułów informacyjnych. ESS jest głównym odbiorcą danych i systemów wewnętrznych ze środowiska zewnętrznego.

Figa. 7.1.

Inne systemy również wymieniają dane. I tu pojawia się jedno z najtrudniejszych pytań dla lidera - poszukiwanie optymalnego stopnia integracji... Kuszące jest posiadanie w pełni zintegrowanego systemu, ale taka integracja jest niezwykle czasochłonna i kosztuje dużo pieniędzy. I lepiej nawet nie mówić, ile kosztuje utrzymanie takiego systemu. Dlatego potrzebę zintegrowanych systemów należy porównać z trudnością i kosztem wielkoskalowych układów scalonych. Nie ma standardowego poziomu integracji lub centralizacji - każdy lider musi niezależnie (lub z pomocą firmy konsultingowej), aby rozwiązać ten trudny problem.

Powiązania między DSS i TPS, KWS,