Bevezetés

A vizsgált cím a Donetsk Donetsk Manufaktúra alapján történik a Cleonelly Store számára.

Az OAO Donetsk Manufaktúra egyik vezető tevékenysége széles körben, többnyire fürdőköpennyel, lemezekkel és törölközőkkel varrási termékeket termel. Ezenkívül a vállalat festett pamutfonalat termel a szövéshez és a kötött termeléshez.

Az automatizált információs technológiák fejlesztése párhuzamosan az új típusú technikai eszközök kialakulásával és az információ továbbításával, a számítógépes felhasználás szervezeti formáinak javítása, az infrastruktúra telítettsége új kommunikációs eszközökkel. A piaci kapcsolatok fejlesztése új típusú vállalkozói szellemek kialakulásához vezetett, és mindenekelőtt az információs üzleti tevékenységben részt vevő vállalatok létrehozásához, az információs technológiák fejlesztése, azok javulása, az automatizált információs technológiák összetevői terjedése Az információs és számítástechnikai folyamatok automatizálása. Közé tartozik a számítástechnikai berendezések, kommunikáció, irodai berendezések és bizonyos típusú szolgáltatások - információk, műszaki és tanácsadási szolgáltatások, képzés stb. Ez hozzájárult az információs technológiák gyors terjesztéséhez és hatékony felhasználásához vezetői és ipari folyamatokban, gyakorlatilag széles körben elterjedt alkalmazások és nagy sokrétű.

A különböző célú eszközök tervezésével és fejlesztésével foglalkozó vállalkozások jelenleg különböző eszközöket használnak mind az automatizált design - capr (CAD), valamint a termelési folyamatok - ASUTP (SCADA / DCS). A saját fejlesztési eszközök esetében azonban saját teljesítményüket és termékminőség-elemzésének ellenőrzését kell kifejleszteni.

A Cleanelly Store raktárban lévő termékek figyelembe vételének technológiai folyamata magában foglalja az eladott áruk tartásának szakaszát.

A jelenlegi érettségi projekt célja az automatizált munkahely (AWA) megvalósítása, amely lehetővé teszi a termék számlázását a bolt raktárában.

A fenti cél eléréséhez a következő feladatokat kell megoldani:

¾ a bolt üzleti folyamatok elemzéséhez;

¾ Fedezze fel a kifejlesztett termék szakaszában felmerülő információkat;

¾ Koncepcionális és logikai adatmodell kialakítása;

¾ Szoftverek fejlesztése a termékek előmozdításához

¾ Az információs rendszer gazdasági hatékonyságának értékelése.

1 A szoftverkövetelmények fejlesztése

1.1 A meglévő megoldások elemzése

Jelenleg számos olyan vállalat létezik, amelyek összekapcsolják mind a termékek közvetlen fejlődését, így a termékek kezelésére szolgáló rendszerek fejlesztése. Az ilyen rendszereket olyan széles körben ismert vállalatokként fejlesztik, mint 1: a vállalkozással és a "csillaggal". Ilyen rendszerekben ellenőrizni kell a megfigyelő anyagokat és feldolgozását.

"1c: Enterprise" az egységes elvek és egy technológiai platform szerint épített alkalmazott megoldások rendszere. A fej választhat olyan megoldást, amely megfelel a vállalkozás jelenlegi igényeinek, és továbbra is fejleszteni fogja a vállalkozást, vagy bővíti az automatizálási feladatokat.

Az "1c: Enterprise" program program célja, hogy megoldja a számviteli és menedzsment automatizálási feladatok széles skáláját, amelyek dinamikusan fejlődnek a modern vállalkozások számára. Helyi számviteli és menedzsment feladatok megoldása Az "1c: Enterprise" program összetétele a vállalkozások jelenlegi igényeire összpontosul. A vállalat "1c" termel forgalmi szoftver megoldásokat, amelyek célja a tipikus számviteli és menedzsment feladatok automatizálására a vállalkozásokban. Az "1c" vállalat keringési megoldásainak megkülönböztető jellemzője a tipikus megoldásokban szereplő funkcionalitás összetételének gondos vizsgálata. Az "1c" vállalat elemzi az "1c: Enterprise" programot használó felhasználók tapasztalatát, és nyomon követi az igényeik változását.

Rendszerem fő előnyei, a nagykereskedelmi bázis a rendszer bevezetésének viszonylagos alacsony költségének tulajdonítható, valamint számos előnye:

¾ A létrehozott alkalmazások megbízhatósága. A szoftvercsomag (PC) stabilnak kell lennie, nemcsak a felhasználói hibák, hanem a kommunikációs rendszer hibáinak is.

¾ az interfész egyszerű használata;

¾ A rendszer magas biztonsági szintje, amely nemcsak az egyes rendszererőforrások rendelkezésre állását és az információk biztonságát szabályozza a működés minden szakaszában, hanem a nagy megbízhatóságú intézkedéseket is.

1.2 A téma területének elemzése

A témakör elemzésének sajátossága az, hogy lehetővé teszi a szervezet teljes működési sorát.

Az üzleti folyamatok elemzéséhez és átszervezéséhez az ügy célja – Legfontosabb szerszám Minden Fúziós folyamat modellező (BPWIN), az IDEF0 módszerek (funkcionális modell), a DFD (DataFlow Diagram) és az IDEF3 (munkafolyamat-diagram) támogatása. A BPWIN egy erőteljes szoftveres termék olyan modellek létrehozásához, amelyek lehetővé teszik a komplex üzleti folyamatok változásainak elemzését, dokumentumát és tervezését. A BPWIN olyan eszközt kínál, amely összegyűjti az összes szükséges információt a vállalkozás munkájáról és az információ grafikus képéről holisztikus és következetes modell formájában.

A rendszer funkcionalitásának szempontjából. Az IDEF0 módszertan részeként az üzleti folyamatot az üzleti folyamatot olyan elemek formájában mutatják be, amelyek kölcsönhatásba lépnek egymással, és az egyes munkák által fogyasztott információkat, emberi és termelési erőforrásokat is mutatnak. A funkcionális modellt úgy tervezték, hogy leírja a meglévő üzleti folyamatok a vállalkozásban (az úgynevezett as-IS modell) és a dolgok ideális helyzetét – Mit kell törekednie (modell-be). Az IDEF0 módszertan előírja a hierarchikus diagramrendszer építését, azaz A rendszerfragmensek egyetlen leírása. Először is, a rendszer a rendszer egészét és kölcsönhatását írja le a külvilággal (kontextuális diagram), amely után egy funkcionális bomlást tartanak – A rendszer alrendszerre oszlik, és minden rendszert külön ismertetünk (bomlási diagramok). Ezután minden alrendszer kisebb és így tovább, hogy elérje a kívánt diplomát.

Ha a modellezés során a vállalati technológia sajátos oldalainak megvilágítására van szükség, a BPWIN lehetővé teszi, hogy a DFD vagy az IDEF3 jelölés modelljének bármely ágára váltson. A DFD-diagramok (adatáramlás diagramozás) hozzáadhat valamit, ami már tükröződik az IDEF3 modellben, mivel leírják az adatfolyamokat, lehetővé téve, hogy nyomon követhesse az információkat a rendszer belsejében lévő üzleti funkciók között. Ugyanakkor a DFD-diagram figyelmen kívül hagyja az üzleti funkciók közötti kölcsönhatást.

Az elvégzett munka sorrendjének szempontjából. És még pontosabb képet is lehet elérni az IDEF3 diagramok modelljével. Ez a módszer felhívja a figyelmet az események sorrendjére. Az IDEF3 logikai elemeket tartalmaz, amelyek lehetővé teszik az alternatív üzleti folyamatfejlesztési forgatókönyvek szimulációját és elemzését.

A boltboltban futó üzleti folyamatoknak csak két IDEF0 és DFD-módszert kell használni. Az IDEF0 rendszerben lévő bármely rendszer modellezésének folyamata a kontextus meghatározásával kezdődik, azaz A rendszer vagy az üzleti folyamatok leírásának legvonzóbb szintje általában.

IDEF0 modell . Az üzleti folyamatok feltárása "A szállító rendelésének kialakítása", "Árbevétel", "áruk nyaralása", tekintse meg az IDEF0 diagram formájában bemutatott grafikonokat. IDEF0 A rendszert interaktív munkák vagy funkciókészleteként képviselik.

Az IDEF0 módszertan négy alapfogalomn alapul.

Az első a koncepció funkcionális blokk (Tevékenység doboz) . A függvényblokk grafikusan ábrázolva téglalapként ábrázolva, és bizonyos konkrét funkciót is személyesít a vizsgált rendszer keretében.

A funkcióblokk négy oldalának mindegyike saját határozott értéke (szerepe), míg:

A felső oldal a "Control" értéket tartalmazza;

A bal oldalon "bemenet" (bemenet);

A jobb oldali "kimenet" (kimenet);

Az alsó oldalnak van az "mechanizmus" értéke.

A második "bálna" IDEF0 módszertan egy interfész Arc (nyíl) koncepciója. Az interfész grafikus kijelzője egyirányú nyíl. Minden interfésznek neve kell nevét (nyíl címke). Az interfész ívek használata, különböző objektumok megjelenítése, egyfokozatú vagy másik, a rendszerben előforduló meghatározó folyamatok. Ugyanakkor a nyilak, attól függően, hogy melyik a munka szélének széle, vagy melyik él kialszik, oszlik ki:

Bemeneti nyilak (a függvényblokk bal oldalán) - az adatok vagy objektumok a működés közben változtathatók;

Menedzsment nyíl (a függvényblokk felső felületén szerepel) - ábrázolja a szabályokat és a korlátozásokat, köszönhetően, hogy mely munkát végzik;

A kilépési nyilak (jönnek ki a funkcióblokk jobb oldalán) - ábrázolják azokat az adatokat vagy objektumokat, amelyek a munka eredményeként jelennek meg;

A mechanizmus nyílja (a funkcióblokk alsó felülete) - az erőforrások (például berendezések, emberi erőforrások) ábrázolása.

Az IDEF0 harmadik alapkoncepciója bomlás (bomlás). A bomlás elvét alkalmazzák, ha a komplex folyamatot a funkció komponenseire osztja.

A bomlás lehetővé teszi, hogy fokozatosan és strukturálódjon, hogy a rendszermodellt az egyes diagramok hierarchikus szerkezetének formájában ábrázolja, ami kevésbé túlterhelt és könnyen felszívódik.

Az utolsó koncepciók az IDEF0 egy szószedet (szószedet). Az IDEF0 elemek mindegyikéhez: diagramok, funkcióblokkok, interfész ívek A meglévő szabvány magában foglalja a megfelelő definíciók, kulcsszavak, narratív bemutatók stb. Létrehozását és fenntartását, amely jellemzi az elem által megjelenített objektumot. Ezt a készletet szószedetnek nevezik, és az elem lényegének leírása.

Tekintsük az üzleti folyamatok diagramját, amely a boltban DMM, Cleonelly:

A rendszer általános láthatóságára a "Enterprise Warehouse" "tevékenységének" összefüggését kell építeni (lásd az 1.1 ábrát).

1.1 ábra - Diagram "raktári tevékenységek"

A kontextus telepítése után bomlást hajtanak végre, vagyis A következő diagramok építése a hierarchiában.

Minden egyes későbbi diagram részletesebb leírása a magasabb táblázatban. A kontextuális munka bomlásának példája az 1.2. Ábrán látható. Így az egész rendszer alrendszerekre oszlik a kívánt részletszintre, ez a rendszer három szintre oszlik.

1.2. Ábra - Első szintű bomlási táblázat

1.3 ábra - Diagram "Terméktervezés"

1.4. Ábra - Diagram "áruk nyaralása"

1.5 ábra - Diagram "hívás áruk"

DFD. Ennek a módszernek az alapja az elemzett IC - vetített vagy ténylegesen létező modell modellje. A módszer szerint, a rendszer modell úgy definiáljuk, mint egy hierarchia adatfolyam diagramok (DFD), amely leírja az aszinkron folyamat átalakításának információt a bemenetét a rendszer kiadása előtt a felhasználó. A DFD-diagramok általában a szervezeti dokumentumkezelő rendszer jelenlegi munkájának vizuális képére épülnek. Leggyakrabban a DFD-diagramot az IDEF0-ben készült üzleti folyamatok modelljének kiegészítésére használják.

Az adatfolyam-diagramok fő összetevői:

Külső entitások (grafikusan ábrázolt négyzet) - jelezzen egy anyagi tárgyat vagy egy személyt, amely az információ forrása vagy vevője. Például: ügyfelek, személyzet, beszállítók, ügyfelek, raktár;

Rendszerek / alrendszerek (grafikusan úgy néz ki, mint egy kerekített sarkok téglalap) - Munka, amely az információk feldolgozását és megváltoztatását jelzi;

Adatmeghajtók - absztrakt eszköz az információk tárolására, amely bármikor elhelyezhető a meghajtóban, és egy idő után kivonni, és a helyiség és az extrakció módja lehet. Az adattároló eszköz általában a jövőbeni adatbázis prototípusa, és az általa tárolt adatok leírása az információs modellhez kell kapcsolódnia;

Adatfolyamok - meghatározza a forrásból a vevőkészülékhez való csatlakozás után továbbított információkat. A diagramon lévő adatfolyamot egy végső nyíllal ábrázolja, amely az áramlási irányt mutatja.

Tekintsünk egy adatfolyam-diagramot (DFD) "áruk nyaralását" 1.6. Ez az ábra bemutatja a dokumentumok mozgását az "Áruk iránti kérelmek" szervezetbe való belépéskor.

1.6 ábra - DFD diagram "áruk nyaralása"

Tekintsük az adatfolyamok alábbi ábráját "Terméktervezés" (lásd az 1.7. Ábrát). Itt látható a munka és a dokumentumok mozgásának folyamata az "áruk kiadásában".

1.7. Ábra - DFD-diagram "Termékregisztráció"

Az adatfolyam diagramok, az összes felhasznált karakter süllyeszteni a közös kép, amely egy világos elképzelése, milyen adatokat használnak, és milyen feladatokat látja el a dokumentumkezelő rendszer. Gyakran megállapítja, hogy a vállalat tevékenységei szempontjából fontos meglévő információáramlások megbízhatatlanok, és át kell szervezni. *******

A Terry Termékek értékesítésével foglalkozó vállalkozás szervezeti felépítése a Cleonelly Store "Donetsk Manufaktúra M" cég példáján szerepel:

A vezérlőrendszerek és a számviteli anyagok fejlesztésének irányában a problémák sikeresen megoldhatók:

1. Ez szabályozza a szállított és tárolt árukat.

2. A beszállítókról és a fogyasztókról

3. Információs információkat és műveleteket is tartalmaz a termék számára.

4. tartalmazza a kiadott áruk jelentési naplóját.

5. Áruk igazolás

6. A raktárfunkciók automatizálása (érkezés, fogyasztás, leírás, termékfoglalás)

7. A megvásárolt és eladott árukra és szolgáltatásokra vonatkozó számlák nyilvántartása és tárolása, valamint az előtörlesztési számlák kivonata, a kifizetés késedelmével és az áruk szállításával

8. A kiadott áruk költsége és elszámolása

9. A raktárak leltárja az oldalsó víz megteremtésével, a hiányhiány és a többlet hiánya

10. Árukkészletek létrehozása

Amint azt a vállalkozás fő tevékenységi területe jelzi, a pamuttermékek értékesítése. A tervezési folyamat számos lépést tartalmaz a projektvállalkozások irányítási struktúrái által a vállalkozás teljes élettartama alatt. Ez a folyamat egyszerre nem változtatható meg, mivel magában foglalja a vállalkozás, a külső alvállalkozók és a projektvállalat ügyfelei számára. Ezért óvatossággal rendelkező vállalkozások kapcsolódnak a tervezési és fejlesztési irányítási folyamatokkal kapcsolatos információs rendszerek megvalósításához. Rendszerint az orosz vállalkozások saját fejlesztésüket használják ezen a területen.

1.3 Gyűjtési követelmények

Tervezésekor egy információs rendszer (IP) „ARTS nagykereskedelmi áruház”, szükséges volt, hogy összegyűjtse a követelmények, amelyek segítenek egy interfész, oly módon, hogy a végfelhasználó (bolt alkalmazottja) volt kényelmes munkát a fejlett IP.

A követelmények kidolgozása olyan folyamat, amely magában foglalja a rendszerkövetelmények specifikációját tartalmazó dokumentum létrehozásához szükséges tevékenységeket.

A számviteli és ellenőrző anyagok folyamatának megvalósításához szükséges, hogy az információs rendszer elvégezhesse a következő funkcionális követelményeket:

¾ Az eredmények dokumentálása.

¾ Az információs rendszert programként kell végrehajtani egy integrált vizuális FOX Pro környezet alapján.

A program a Windows 2000 / NT / XP operációs rendszerben történik.

A fejlesztési követelmények folyamatának négy fő szakasza van (1.8. Ábra):

A rendszer létrehozásának technikai megvalósíthatóságának elemzése;

A követelmények kialakítása és elemzése;

A követelmények előírásai és a vonatkozó dokumentáció megteremtése;

A követelmények igazolása.

A gyűjtési követelmények fontos lépés a tervezési tervezésben, mivel itt van, hogy az ügyfél minden követelményének helyesnek kell lennie, és helyesen van megfogalmazva.

1.4 A követelmények meghatározása

A helyes követelmények meghatározása valószínűleg a szoftverprojekt legelismertebb szakasza. Nagyon fontos, hogy a projektformátum összhangban legyen a fejlesztői csapat által gyűjtött szoftverekre vonatkozó követelményekkel, különben ezek a követelmények nem fognak támogatni és bemutatni a szoftvertermékben. Szoftver Szoftver követelmények Software-előírás (SRS) kulcsfontosságú a teljes szoftverfejlesztési életciklus. Ez nem csak olyan derivatív dokumentum, amelyben a program projekt előírásai, hanem a tanúsítási és elfogadási tesztek elvégzésére alkalmazott fő okmány is. A tanúsítás a projektmenedzserek munkájának minőségének értékelése. Meghatározza a szoftvertermék által meghatározott követelményeknek való megfelelés mértékét. Az SRS specifikáció a rendszerkövetelmények rögzítésére szolgáló mechanizmusként működik, amelyeket a tanúsítás kritériumaiként használnak.

Az SRS alapján az ügyfelek és a szoftvergyártók között hozzájárulnak. Az SRS-specifikáció teljes mértékben leírja a szoftvertermék fejlesztését. Ez lehetővé teszi a potenciális felhasználók számára, hogy meghatározzák az igényeiknek való megfelelés mértékét, valamint a termékmódosítási útvonalakat annak érdekében, hogy a lehető leghosszabb legyen a feladatok megoldása során.

Ideiglenes fejlesztési költségek fejlesztése. Az SRS-specifikációk előkészítése különböző csoportokat érintett az ügyfél szervezésében. Óvatosan megvizsgálják az összes követelményt, még mielőtt a projekt közvetlen fejlődése megkezdődik. Ez csökkenti a projekt későbbi fejlesztésének valószínűségét, a kódolást és a tesztelést.

Az SRS-specifikációban bemutatott követelmények alapos vizsgálatával lehetséges a túladagok, félreértések és ellentmondások felderítése a fejlesztési ciklus korai szakaszában, amikor a problémák sokkal könnyebbek, mint a későbbi szakaszokban.

Az SRS specifikáció a munka ütemezésének költségeinek becsléséhez és elkészítéséhez szükséges. A termékleírás valóságos alapja a projekt költségeinek becsléséhez. Olyan környezetben, ahol a formális javaslat fogalma van, az SRS-t az ajánlat vagy ár értékelésének jóváhagyására használják.

A javasolt SRS specifikációk segítségével a szervezet szintjén a szervezet sokkal produktívabb terveket alakíthat ki tanúsításról és ellenőrzésekről. A fejlesztési szerződés részeként az SRS referenciapontot nyújt a specifikációk betartásának értékelésére.

Az SRS-specifikációnak köszönhetően a programterméket az új felhasználók, valamint a más számítógépekre való telepítésével is megkönnyítik. Így könnyebbé válik az ügyfelek számára, hogy a szoftverterméket a szervezet más egységeire és a fejlesztőkre továbbítsák más ügyfeleknek.

Az SRS specifikáció alapja a frissítés alapjául szolgál. Ez a dokumentum magában tárgyalja a terméket, és nem a projektfejlesztési folyamatot, ezért lehetőség nyílik a kitöltött termék ki bővítésére.

Miután a meghatározási folyamat és a specifikációk befejeződnek, szükség van a követelmények igazolására.

A szoftverprojekt követelményeinek specifikációját az A. függelékben kell bemutatni.

1.5 A követelmények igazolása

A tanúsításnak bizonyítania kell, hogy a követelmények valóban meghatározzák azt a rendszert, amelyet az ügyfél akar. A követelmények ellenőrzése fontos, mivel a követelmények előírásai a rendszerváltoztatáshoz és a magas költségekhez vezethetnek, ha azok a rendszerfejlesztés rendszere vagy üzembe helyezése után észlelhetők.

A tanúsítási folyamat során különböző típusú dokumentációs ellenőrzéseket kell végrehajtani:

1. Ellenőrizze a követelmények helyességét.

2. Ellenőrizze a következetességet.

3. Ellenőrizze a teljességet.

4. Ellenőrizze a megvalósíthatóságot.

Számos tanúsítási módszer létezik, amelyek külön-külön alkalmazhatók, vagy külön-külön:

1. A követelmények felülvizsgálata.

2. Prototípusozás.

3. A vizsgálati forgatókönyvek generálása.

4. Automatizált konzisztenciaelemzés.

Az ügyfélrendszer leglátványosabb a prototípus.

Mielőtt elkezdené a prototípusok létrehozását, létrehozhat egy felhasználói felület stream diagramot. Ez a diagram a felhasználói felület fő elemei közötti kapcsolat felfedezésére szolgál.

A követelmények tanúsításának következő lépése a prototípusok közvetlen létrehozása.

A szoftver prototípusa a javasolt új termék részleges vagy lehetséges végrehajtása. A prototípusok lehetővé teszik a három fő feladat megoldását: a követelmények megfogalmazásának tisztázása és befejezése, az alternatív megoldások kutatása és a végtermék létrehozása.

A modul főmenüjének prototípusa az 1.9. Ábrán látható.

1.6 Az információs rendszer tervezési módszertan kiválasztása

Az IP fejlesztésének strukturális megközelítésének lényege az automatikus funkciók bomlása (partíció) az automatizált függvényeken: a rendszer funkcionális alrendszerekre oszlik, ami viszont feladatokra osztva alfunkciókra oszlik. A particionálási folyamat továbbra is konkrét eljárásokra van szükség. PI Ez az automatizált rendszer olyan holisztikus ábrázolást tart fenn, amelyben minden összetevő összekapcsolódik.

A strukturális megközelítés minden legelterjedtebb módszerei számos általános elven alapulnak. A következő elveket két alapelvként használják:

A "megosztottság és meghódítás" elve az összetett problémák megoldásának elve a sok kisebb független feladatot, könnyen megérthető és megoldható;

A hierarchikus megrendelés elve a probléma komponenseinek a hierarchikus fa struktúrákba való szervezésének elve az új részek hozzáadásával minden szinten.

A strukturális elemzésben elsősorban két olyan pénzcsoport van, amely a rendszer által végzett funkciókat és az adatok közötti kapcsolatot szemlélteti. Minden pénzcsoport megfelel bizonyos típusú modellek (diagramok), a leggyakoribb, amelyek közül a következők:

SADT (Structud \u200b\u200banalízis és design technika) modellek és megfelelő funkcionális diagramok;

DFD (adatáramlási ábrák) adatfolyam-diagramok;

ERD (entitás-kapcsolat-diagramok) Chart "essence-kommunikáció".

A IC modell tervezési szakaszában bővíti, finomítja és kiegészíti a szoftverstruktúrát tükröző diagramokat: a szoftver architektúrája, a programok strukturális rendszerei és a képernyőn megjelenő diagramok.

A felsorolt \u200b\u200bmodellek az aggregátumban teljes mértékben leírják az IC-t, függetlenül attól, hogy létezik-e vagy újonnan fejlett. Az egyes konkrét esetekben az ábrák összetétele a rendszer leírásának szükséges teljességétől függ.

2 információs rendszer tervezése

2.1 Építészeti tervezés

Bonyolult információs rendszer létrehozásakor a kritikus szempont az architektúra, ahol a jövőbeni funkcionális folyamatok és technológiák szerkezetének koncepcionális elképzelése a rendszer szintjén és a kapcsolatokban. Jellemzően a szervezetek összetett információs rendszereit úgy tervezték, mint a magas szintű komponensek összetétele, amely maguk is rendszerek lehetnek. A szervezet információs rendszerének architektúrája könnyebbé teszi a rendszert a funkcionalitás és a szerkezet meghatározásával olyan módon, amely feltárja a tervezési megoldásokat, és lehetővé teszi a böngésző számára, hogy kérdéseket tegyen fel a tervezési követelmények megelégedésére, a funkcionalitás elosztásáról és a megvalósításról alkatrészek.

A szervezet információs rendszerének architektúrája az a modell, hogy az információs technológia hogyan támogatja az automatizált objektum fejlesztésének fő célkitűzéseit és stratégiáját. Lehetővé teszi, hogy kritikusan gondolkodj és egyértelműen kifejezze azon álláspontját, hogy az integrált információs rendszerek beépítése az e célok megvalósítása érdekében. Az információs rendszer architektúrája leírja, hogy az információs rendszerek, az alkalmazások és az emberek az egész szervezeten belül egységes módon működjenek együtt.

Így az információs rendszer architektúrája tartalmaz egy általánosan elfogadott alkatrészkészletet, amelyek az információs rendszer "építőelemek" részét képezik. Ezeket az "építőelemeket" és azok jellemzőit a megfelelő részletességi szinten határozzák meg, hogy megfeleljenek a tervezési megoldások által elvégzett igényeknek.

A szervezetek modern információs rendszereinek megtervezése során az architektúrát számos érdekelt fél figyelembevételével kell kidolgozni, érthetőnek kell lennie a felhasználóknak, hogy a fejlesztők a rendszer tervét és grafikonjait, lehetővé tegyék a kulcsfontosságú interfészek, funkciók és technológiák meghatározását , és lehetővé teszi, hogy értékelje az ütemtervet és a projekt végrehajtási költségvetését. Ugyanakkor a modern információs rendszerek építészei a fejlődés legkorábbi szakaszában kielégítő és végrehajtó rendszer koncepciójának felelősséget igényelnek, amely e koncepció integritását támogatja az ebből eredő rendszer használatának eredménye és meghatározása során az ügyfél. Másrészt az információs rendszer architektúrájának fejlesztése az a folyamat, hogy elegendő részletességgel leírja az információs rendszerek architektúráját, hogy hasznosabbá tegyék az információs rendszerek fejlesztéséhez.

A külföldi tapasztalatok tanulmányozása azt mutatja, hogy a fejlett országokban az információs rendszer architektúrájának kialakításakor a következő feltételeknek való megfelelést igényli:

¾ a szervezet küldetésére összpontosít;

¾ a követelményekre összpontosít;

¾ a fejlesztésre összpontosít;

¾ az alkalmazkodási képesség;

¾ A rugalmasság szükségessége.

Mindezen feltételeknek való megfelelés lehetővé teszi, hogy a szervezet információs rendszerének architektúráját tökéletesebbé és hatékonyabbá tesszük.

A jelenleg végrehajtott fő szoftver architektúrák:

¾ fájl-kiszolgáló;

¾ kliens-kiszolgáló;

¾ Többszintű.

Fájlkiszolgáló. . A hálózati hozzáféréssel rendelkező központosított adatbázisok ezen architektúrája magában foglalja az egyik hálózati számítógépek hozzárendelését olyan dedikált szerverként, amelyen a központi adatbázisfájlok tárolódnak. A felhasználói kéréseknek megfelelően a kiszolgálófájlból származó fájlok továbbítják a felhasználói munkaállomásoknak, ahol az adatfeldolgozás fő részét elvégzik. A központi kiszolgáló elsősorban a fájlok tároló szerepét végzi, anélkül, hogy részt vett volna az adatok feldolgozásában. A felhasználók befejezése után a felhasználók másolják a feldolgozott adatokkal rendelkező fájlokat a kiszolgálóhoz, ahonnan más felhasználók is elvégezhetik és feldolgozhatják. Az ilyen adatszervezetnek számos hátránya van például, míg egyidejűleg a felhasználók egy és ugyanazon adatkészletét egyidejűleg kezeli, a munka teljesítménye élesen van, mivel meg kell várni, amíg az adatokkal együtt dolgoznak a munka. Ellenkező esetben lehetőség van az egyik felhasználó által végrehajtott korrekciók, más felhasználók által végrehajtott korrekciók megerősítésére.

Ügyfélszerver. . Ez a koncepció azon az ötleten alapul, hogy az adatbázisfájlok tárolása mellett a központi szervernek az adatfeldolgozás fő részét kell elvégeznie. A felhasználók lásd a központi szerver segítségével a speciális nyelve strukturált lekérdezések (SQL, Structured Query Language), amely leírja egy listát a feladatokat a szerverre. A felhasználói kérelmeket a kiszolgáló elfogadja, és adatfeldolgozási folyamatokat generál. Válaszul a felhasználó már feldolgozott adatkészletet kap. Nem az egész adatkészletet továbbítják az ügyfél és a kiszolgáló között, mint a fájlkiszolgáló technológia, de csak az ügyfél szükséges adatai. A felhasználói kérés csak néhány sor hosszában képes egy adatfeldolgozási folyamat létrehozására, amely több asztalt és több millió vonalat érint. Válaszul az ügyfél csak néhány számot kaphat. Az ügyfél-kiszolgáló technológia lehetővé teszi, hogy elkerülje az átvitel hatalmas mennyiségű információ hálózaton keresztül az összes adatfeldolgozás a központi szerveren történő áthelyezésével. Ezenkívül a szóban forgó megközelítés lehetővé teszi, hogy elkerülje a változások ütközését az azonos adatokban, akik a fájl-kiszolgáló technológiájára jellemzőek. A technológiai ügyfél-kiszolgáló egységes adatcserét hajt végre több kliensben, biztosítva az adatok integritásának automatikus betartását. Ezek és más előnyöket nagyon népszerűvé tették az ügyfél-kiszolgáló technológiát. Ennek a technológiának a hátrányai közé tartoznak a központi szerver teljesítményének magas követelményei. Minél több ügyfél található a szerverre, és minél több az adatok feldolgozása, annál erősebbnek kell lennie egy központi szervernek.

Ezen indokolás alapján az AWP architektúrájának kialakítása alapul, a technológiai ügyfél-kiszolgálót elfogadták. Az elhelyezési táblázatok tükrözik a rendszer szoftver és hardverelemei közötti fizikai kapcsolatokat).

2.2 Az információs rendszer interfészének megtervezése

A felhasználói felületen gyakran a program megjelenése gyakran érthető. Valójában a felhasználó az egész rendszert egészen az egész rendszeren keresztül érzékeli, ami azt jelenti, hogy megértése túl keskeny. Tény, hogy a felhasználói felület tartalmazza a felhasználói interakciót és a rendszert érintő tervezés minden szempontját. Ez nem csak egy olyan képernyő, amelyet a felhasználó lát. A felhasználói felület számos komponensből áll, mint például:

olyan felhasználói feladatok sorozata, amelyek megoldják a rendszert;

Rendszergazdálkodási elemek;

a rendszerblokkok közötti navigáció;

A program képernyők vizuális tervezése.

Kiemeljük a jó felhasználói felület egyik legjelentősebb előnyeit az üzleti szempontból:

A felhasználói hibák számának csökkentése;

a rendszertámogatás költségeinek csökkentése;

a munkavállalók termelékenységének csökkenése a rendszer végrehajtásában és az elveszett termelékenység gyorsabb helyreállítása;

a személyzet erkölcsi állapotának javítása;

A felhasználói felület megváltoztatásának költségeinek csökkentése a felhasználók kérésére;

A rendszer funkcionalitásának hozzáférhetősége a felhasználók maximális számához.

Az AWP nagykereskedelmi bázis az ügyfél-kiszolgáló technológiával történő alkalmazásként alakul ki.

2.2.1 Felhasználói felületkezelési program

A "Arts Wholeale Base" fő modul a Luck.exe modul, amely biztosítja az 1.4. Ábrán bemutatott 1.9.

Amikor az egyik fő feladat információs rendszerének fejlesztése során a legegyszerűbb és kirakott felület létrehozása. Ez a program termékinterfésze, amely segít a "kommunikálni" az információs rendszerrel, felhasználói kommunikációs párbeszédpanelként és rendszerként.

Program interfész, adminisztrátor:

1. A program kezdeti formája. Ez a formanyomtatvány elindul, ha a szoftvert elindítja, így a felhasználó párbeszédablakának kezdete a rendszerrel (2.3. Ábra);

2. Adminisztrátori forma. Ebben az űrlapon az információs rendszer teljesen ellenőrzött, azaz Adatok hozzáadása, törlése, módosítása az adatbázisban, valamint szükség esetén megtekintési és nyomtatási jelentések (2.4. Ábra);

3. Az "Ügyfelek" formája ennek az űrlapnak köszönhetően teljes információt találhat az Enterprise ügyfeleiről (2.7. Ábra);

4. A "Szállítók" formanyomtatványok e formanyomtatványnak köszönhetően teljes információkat láthatunk az Enterprise ügyfeleiről (2.8. Ábra).

Program interfész Egyéni rész:

Az ablakban az áruk érkezése az áruk tervezése. Ha ez a lap van kiválasztva, a felhasználónak először kell

A fogyasztási menüben a munkaraktár működése az áruk nyaralására és értékesítésére.

A maradék menüben a termék száma, a tárolt tárolt tárolt neve.

A pénztáros menüben a plébánia megrendelésekre és a fogyó készpénz-megrendelésekre vonatkozó információk tárolódnak. (Képernyőképek)

2.2.2 Felhasználói interfészek vezérlőelemek

2.0. ábra A program főmenüje

A program főablakát az 1. ábrán mutatjuk be. 1.9. Amint az az ábrán látható, a fent leírt főmenü mellett is tartalmaz egy vezérlőpanelt ("érkezés" gombok, "fogyasztás", "hozzáférés", "marad", "pénztáros", "átértékelés "," Analytics "," References "," Service "és" Kilépés a programból ").

2.1 ábra Az eljövendő menü ablaka vagy a raktárba való felvétel.

2.2 ábra áramlás menüablaka

2.2. Ábra Menü ablak A hozzáférési jogok módosítása a programhoz.

2.3 ábra Az áruk ablak menüje.

2.4. Ábra Készpénz menüablak.

2.4 ábra Ablak menü átértékelése.

2.3 Adatbázis-tervezés

Az ERWIN 4.0-t a számítógépes társultaktól az adatbázis tervezésére használták.

Az Erwin egy erős és könnyen használható adatbázis-tervező eszköz, amely széles körben elterjedt felismerést és népszerűséget szerzett. Ez biztosítja a legmagasabb termelékenységet az adatbázisok felhasználásával történő alkalmazások fejlesztése és fenntartása során. Az egész folyamat során az adatbázist meghatározó információs és üzleti szabályok logikai modellezési követelményeitől kezdve, mielőtt a fizikai modellt a megadott jellemzőknek megfelelően optimalizálná - Erwin lehetővé teszi, hogy vizuálisan megjelenítse az adatbázis szerkezetét és alapvető elemeit.

Az Erwin nem csak a legjobb eszköz az adatbázisok tervezéséhez, hanem azt is jelenti, hogy gyorsan megteremti őket. Erwin optimalizálja a modellt a célbázis fizikai jellemzőivel összhangban. Az egyéb eszközökkel ellentétben az Erwin automatikusan fenntartja a logikai és fizikai rendszerek koherenciáját, és átalakítja a logikai struktúrákat, például a sok-sok-sokakat, megvalósításuk során a fizikai szinten. Megkönnyíti a tervezési adatbázisokat. Ehhez elegendő egy grafikus E-R modell (objektum-hozzáállás) létrehozása, amely megfelel az összes adatkövetelménynek, és beviteli az üzleti szabályokat, hogy hozzon létre egy logikai modellt, amely megjeleníti az összes elemet, attribútumot, attitűdöt és csoportosulást. Erwinnek két szintje van a modell bemutatójával - logikai és fizikai. A logikai szint az adatok absztrakt nézete, azt bemutatják rajta, ahogyan a valós világban néznek, és hívhatják, ahogyan azt a valós világban hívják, például "állandó ügyfél", "osztály" vagy "A munkavállaló családja". A logikai szinten ábrázolt modell tárgya entitások és attribútumok. Az adatmodell logikai szintje univerzális, és semmiképpen sem kapcsolódik a DBMS konkrét megvalósításához. Az adatmodell logikai szintjének három részei vannak, különböznek az adatinformációk bemutatásának mélységében:

Diagram entitás - kommunikáció (entitás kapcsolatok diagram (ERD));

Kulcs alapú adatmodell (kulcs alapú modell (KB));

Teljes attribált modell (FA).

Diagram lényeg - A kommunikáció magában foglalja a tárgykör alapvető üzleti területeit tükröző szervezeteket és kapcsolatot. Ez a diagram nem túl részletes, magában foglalja azokat a főbb szervezeteket és kapcsolatokat, amelyek megfelelnek az alapvető követelményeknek. Diagram lényeg - A kommunikáció magában foglalhatja a "sok, sok" kommunikációt, és nem tartalmazzák a kulcsfontosságú leírásokat. Általános szabályként az ERD-t előadásokra használják, és megvitassák az adatstruktúrát a téma területének szakértőivel. A kulcs alapú adatmodell az adatok részletesebb nézete. Ez magában foglalja az entitások és az elsődleges kulcs leírását, és a témakörnek megfelelő adatstruktúrát és kulcsokat képviseli.

A logikai modell az adatszerkezet legrészletesebb ábrázolása: a harmadik normál formában szereplő adatokat képviseli, és magában foglalja az összes entitást, attribútumokat és kommunikációt (lásd a B. függeléket).

Fizikai adatmodell Éppen ellenkezőleg, egy adott DBMS-től függ, valójában a rendszerkönyvtár megjelenése. A modell fizikai szintje az összes adatbázis objektumra vonatkozó információkat tartalmazza. Mivel nincsenek szabványok az adatbázis-objektumokhoz (például nincs szabvány az adattípusok esetében), a modell fizikai szintje a DBMS konkrét megvalósításától függ. Következésképpen a modell ugyanazon logikai szintje megfelel a különböző modellek különböző fizikai szintjének. Ha a modell nem rendelkezik nagyobb értékkel a logikai szinten, amely kifejezetten az attribútumban található adattípust (bár az absztrakt adattípusok támogatottak), akkor fontos leírni az összes információt a speciális fizikai tárgyakról - asztalok, oszlopok, indexekről , eljárások stb. Az adatmodellek logikai és fizikai szintjének szétválasztása lehetővé teszi, hogy több fontos feladatot megoldhasson.

A fizikai adatmodellt a V. függelék tartalmazza.

2.4 Az információs rendszer létrehozásának platformjának kiválasztásának indoklása

A Visual FoxPro vizuális környezet a Microsoft Corporation által jelenleg gyártott relációs adatbázis-kezelő rendszerek fejlesztéséhez. Az utolsó verzió 9,0. FoxPro programozási nyelvet használ. A 7.0 rendszer verziója Windows 9x operációs rendszerekben és NT kernelben, 8.0 és 9.0 verzióban működik - csak a Windows XP, 2000, 2003 rendszerben.

A FoxPro (Fox-Pro?) Az XBASE programozási nyelvi dialektus egyike. Főként relációs DBMS kifejlesztésére használják, bár lehetőség van a fejlesztési és egyéb programcsoportokra. Amint azt már említettük, a VFP nyelv egy erősen odaítélt és fejlett XBase nyelv. A Visual FoxPro, a programozási nyelv, azaz a nyelv alaptervezése az osztály koncepciója. Az eredeti Xbase verzió a legtisztább struktúra, az eljárások és funkciók alapfogalmával. Így a modern programozási nyelv a Visual FoxPro lehetővé teszi, hogy mindkét programot "a régi módon" írja le, amely leírja az eljárások tömegét és az OOP stílusát, ami összetett hierarchiát hoz létre az osztályok.

Ezt a nyelvi programozást választottam, mert a következő előnyöket tartalmazza:

¾ Az adatbázis táblázatok széles körben ismert formátuma, amely megkönnyíti az információmegosztást más Microsoft Windows alkalmazásokkal.

Modern szervezet relációs adatbázisok, amely lehetővé teszi, hogy tárolja az információt, az asztalok a bázis, azok tulajdonságait, indexek és a linkeket, meg a feltételeknek való megfelelés hivatkozási integritás, hozzon létre helyi és távoli kilátást (Views), kommunikációs szerverekkel, tárolt eljárások végrehajtható több mint 50 különböző típusú esemény előfordulásakor. (VFP 7.0-9.0).

Nagy sebesség nagy adatbázisokkal.

Magas veszteségek adatbázisokkal: Multifunkcionális adatkezelési ablak Lehetővé teszi a nyílt adatbázis táblázatok listáját, azok összekapcsolása, szűrőjei, indexek, pufferelési módok, a módosítás módosításainak módosításához, az asztali információkkal való együttműködéshez stb.

Magas alkalmazásfejlesztési sebesség Masters (varázsló), tervezők, építők (Builder), IntelliSense tippek módban szöveges szöveg, hibakeresési és programvizsgálati rendszerek írásakor.

Az a képesség, hogy alkalmazásokat fejleszteni a kliens-szerver technológia közzétett adatok Oracle és a Microsoft SQL Server adatbázis-kiszolgálók és más Microsoft Windows alkalmazásokhoz ODBC és OLE

A VFP-rendszert professzionális programozók használata céljából úgy tervezték, ezért nincs értelme menüjének és nyelvének oroszul - bármely programozó számára, az algoritmikus nyelv angol szintaxisa hozzászokott, mint az orosz.

2.5 Modulok tervezése

Tartsuk az egyik programmodul kialakítását, és fontolja meg a projektek létrehozásához szükséges lépéseket.

Példaként figyelembe vesszük egy olyan modul kialakítását, amely végrehajtja a használati opciót "A felvételi kérelmet" kéri.

Kezdjük, leírjuk az ebben a kiviteli alakban előforduló események áramát.

Előrehala az alkalmazás alkalmazásához az ügyféltől.

5. A használati opció akkor kezdődik, amikor az ügyfél kérelmet küld.

6. A menedzser megnyitja az érkezés formáját.

7. A menedzser az alkalmazás dátumát adja.

8. A menedzser az áruk nevét hozza.

9. A menedzser hozzájárul a kereskedelmi áruk mennyiségét.

10. A menedzser hozzájárul az alkalmazás összegét.

11. A menedzser bezárja az űrlapot.

12. A használati opció befejeződik.

A használatra fordított fizetés a rendszer alkalmazásának kialakítása és az új kliens megjelenése a fő forma magazinjában.

Tekintsük az alkalmazás szekvenciájának ábráját. Amint ezt a diagramból láthatja, a menedzser, az űrlap megnyitása, több műveletet okozott - automatikusan (a kezelő szempontjából) az alkalmazás dátuma megtörtént. Az ügyfelek listája, amikor az alkalmazás elsődleges információval tölti be az alapot. Ezután a menedzser hozzájárul minden szükséges adatot, és kattint az "Elfogad" gombra. A következő műveleteket hajtják végre. Minden adatot továbbítanak a tárolt eljárásnak.

3 Az információs rendszer végrehajtása és tanúsítása

3.1 Alkalmazás végrehajtása

A végrehajtását a kérelem eleve egyik időigényes szakaszában a fejlesztő az információs rendszer, mert a követelmények, hogy az ügyfél terjeszt elő kell egyértelműen és pontosan integrálható a rendszerbe. Eddig nincs olyan szoftveres termékek, amelyek az úgynevezett ügyfél igényei szerint "alkalmazkodhatnak", és bizonyos funkciókat biztosítanak a rendszer végrehajtásához, amely megfelel ezeknek a követelményeknek. Ezért minden fejlesztőnek választania kell magának az optimális környezetet a rendszer fejlesztésére, de meg kell jegyezni, hogy az alkalmazás végrehajtásakor a programkód írása nélkül nem történik meg. Ez egy olyan programkód írása során, amelyet bizonyos funkciók végrehajtanak, amelyeket a rendszernek végre kell hajtania. A kiválasztott rendszer végrehajtási környezetétől függően a programkód eltérő lesz, mivel egy ilyen médiumban a Microsoft Visual FoxPro egy programkód, a vizuális bázisban, stb.

Ebben az esetben a kérelmet a Microsoft Visual FoxPro-ban hajtották végre.

A rendszer fő funkcióit az alábbiakban ismertetjük:

1. A rendszer indítása. Ez az űrlap egy nyomógombos forma, és ennek megfelelően minden gomb végrehajtja funkcióját. A rendszergazda regisztrációs gombját a 3.1 ábrán mutatjuk be. A gomb végrehajtja az adminisztrátorpanel megnyitó funkciót, ha a felhasználónak ilyen joga van ehhez a rendszerhez

2. A következő menü gomb. A szivattyú lehetővé teszi, hogy rögzítse a bejövő árut a tároló tárolóra 3.2.

3. A MENU gombban a fogyasztás a Raktári Raktár 3.3 ábrájából származik.

4. A Hozzáférés menü gombja beállítja a program használatának jogait a 3.4. Ábra.

5. A maradék maradék menü gombja tárolja a tárolt anyagokról szóló információkat a tároló tárolóban 3.5.

6. A CASSO MENU gomb tárolja az érkezési pénztárgépekre és a kiadási készpénz-megrendelésekre vonatkozó információkat. 3.6.

7. A MENU gombban az átértékelési változások átadják az áruk új árának árát.

3.1 ábra - Startout rendszer

3.2. Ábra - Az anyagbevételek számviteli formája a raktárba.

3.3. Ábra - A kiadott áruk elszámolási formája.

3.4. Ábra - A hozzáférési jogok módosítása a programhoz.

3.5. Ábra - Az áruk egyenlegének formája.

3.5. Ábra-forma a nyereséges pénzbeli megrendelésekről és a fogyó készpénzszabályozásról.

3.6. Ábra az áruk műveleteinek formája.

Tesztelési alkalmazások

A tesztelés a program végrehajtási folyamat a hibák észlelése érdekében. A tesztelés biztosítja:

Hibafelismerés;

A program funkcióinak megfelelőségének bemutatása;

A program jellemzőire vonatkozó követelmények végrehajtásának bemutatása;

Megjeleníti a megbízhatóságot, mint program minőségmutatóját.

A 3.2. Ábra bemutatja a vizsgálati folyamat információáramlásait.

A három patak tesztelésének bejáratánál:

Programszöveg;

Forrásadatok a program megkezdéséhez;

Várható eredmények.

Vizsgálatok történnek, a kapott összes eredmény becsülhető. Ez azt jelenti, hogy a tényleges vizsgálati eredményeket összehasonlítjuk a várt eredményekkel. Amikor az eltérés észlelhető, hiba van rögzítve - a hibakeresés kezdődik.

A vizsgálati eredmények összegyűjtése és értékelése után kezdődik a szoftver minősége és megbízhatósága. Ha komoly hibák merülnek fel a tervezési változásokra, akkor a minőség és a megbízhatóság gyanús, azt a tesztelés szükségessége.

A tesztelés során felhalmozott eredmények becslése és formálisabb módja lehet. Ez a szoftver megbízhatósági modelleket használja, amelyek a hibák intenzitásában megbízhatósági előrejelzést végeznek.

Vannak programvizsgálati elv:

Funkcionális tesztelés (tesztelés "fekete doboz");

Szerkezeti tesztelés ("fehér doboz" tesztelése).

A "Fehér doboz" módszer alkalmazásával a program belső szerkezete ismert. A tesztelés tárgya itt nem külső, hanem a program belső viselkedése. Az összes programelem kiépítésének helyességét és az egymással való kölcsönhatás helyességét ellenőrizzük.

A "Black Box" (funkcionális tesztelés) tesztelése lehetővé teszi a bemeneti adatok kombinációit, amelyek teljes körű ellenőrzését biztosítják a program összes funkcionális követelményeinek. A szoftverterméket "fekete doboznak" tekintik, amelynek viselkedését csak a bemenetek tanulmányozásával és megfelelő kimenetekkel lehet meghatározni.

A "fekete doboz" elve nem alternatív a "fehér doboz" elvének. Inkább ez egy kiegészítő megközelítés, amely észlel egy másik hibaosztályt.

A "fekete doboz" tesztelése a következő hibák kategóriáinak keresését biztosítja:

Helytelen vagy hiányzó funkciók;

Interfész hibák;

A külső adatszerkezetek vagy a külső adatbázishoz való hozzáférés hibái;

Jellemzői hibák (szükséges memória kapacitása stb.);

Inicializálási és befejezési hibák.

A "fehér doboz" tesztelésével ellentétben, amelyet a vizsgálati eljárás korai szakaszában végeznek, a "Black Box" tesztelését a tesztelés későbbi szakaszaiban használják. A "fekete doboz" tesztelése során elhanyagolta a program vezérlőszerkezetét. Itt a figyelem középpontjában a figyelem középpontjában áll a szoftverrendszer meghatározása. Ebben a szakaszban teszteléskor a megoldás alkalmasságának középpontjában áll az életkörülmények között. A hangsúlyt a hibák korrekciójára és annak fontosságuk meghatározására, valamint a kibocsátandó termék előkészítésére kell kifizetni.

A vizsgálati szakaszban két fő feladat megoldódott:

Vizsgálati megoldások - A tervezési szakaszban létrehozott vizsgálati tervek és a fejlesztési fázis során meghosszabbított és teszteltek;

Point Működés - megoldás telepítése tesztkörnyezetben és tesztelés a jövőbeni felhasználók bevonásával és a valós rendszer felhasználási forgatókönyvek végrehajtásával. Ezt a feladatot a telepítési szakasz kezdete előtt végzik.

A vizsgálati szakasz célja, hogy csökkentse a megoldás ipari működésbe való belépésének kockázatát.

A tesztelési szakasz sikeréhez szükséges, hogy a kapcsolat a projekthez forduljon, és a fejlesztő az új funkciók kialakulásából váltott ki a megfelelő minőségű megoldások biztosítására.

Az információs rendszer ezen szakaszában a következő típusú vizsgálatokat kell elvégezni:

Alapvető tesztelés - alacsony szintű műszaki tesztelés. Ezt a fejlesztő maga a programkód írása során végzi. A fehér fiókos módszert használják, a hibák nagy kockázata.

Vizsgálat a használati alkalmassághoz - magas szintű tesztelés, amelyet tesztelő és jövőbeli termékfelhasználók hajtanak végre. A "Black Box" módszer érvényes.

Alpha és Beta tesztelés - az MSF Alfa-Code szempontjából - Ez alapvetően az MSF folyamatmodell fejlesztésének szakaszában létrehozott összes forrásszöveg, és a béta kód a tesztelési fázis során tesztelt kód. Ezért az MSF folyamatmodellének fejlesztése során az Alpha kódot tesztelik, és a vizsgálati szakaszban - Beta kód.

Kompatibilitási tesztelés - a kifejlesztett megoldásból, a meglévő rendszerekkel és szoftveres megoldásokkal való kölcsönhatás képességének integrálására és képességére. Ez a tesztelési forma összpontosul a fejlett megoldás integrálására és képességére, hogy kölcsönhatásba lépjen a meglévő rendszerekkel. Ebben az esetben ellenőrizni fogják az alkalmazási művelet helyességét a felhasználói berendezésen és a felhasználó által használt felhasználó által.

Teljesítményvizsgálat - orientált, hogy ellenőrizze, hogy az alkalmazás kielégíti-e a teljesítmény követelményeit és a sebesség sebességét.

Tesztelési dokumentáció és referenciarendszer - Minden kifejlesztett kísérő dokumentumot és referenciarendszert tesztelnek.

A kísérleti művelet az ipari környezetben végzett megoldásokat vizsgálja. A kísérleti művelet fő feladata annak bizonyítása, hogy a megoldás képes stabilan dolgozni az ipari kiaknázással, és megfelel az üzleti követelményeknek. A kísérleti művelet folyamatában a megoldást valós körülmények között vizsgáljuk. A pont művelet lehetővé teszi a felhasználók számára, hogy kifejtsék véleményüket a termék munkájáról. Ezzel a véleménygel a fejlesztő megszünteti az összes lehetséges problémát, vagy előre nem látható körülmények esetén létrejött valamennyi lehetséges problémát vagy cselekvési tervet hoz létre. Végső soron a kísérleti művelet lehetővé teszi, hogy eldönthesse, hogy elindít egy teljes körű telepítést vagy elhalasztást, mielőtt a telepítés megszakítására képes hibaelhárítás.

A kidolgozott információs rendszer kísérleti folyamattervét a 3.2. Táblázat tartalmazza.

3.2. Táblázat - Pilot működési terv

törvény		Leírás
1. A siker kritériumok kiválasztása		A tapasztalt tesztelés fejlesztője és résztvevői meghatározzák a siker kritériumait és összehangolják őket
2. A felhasználók és a telepítési helyek kiválasztása		A résztvevők csapata a tapasztalt tesztelésben a felhasználóktól és a fejlesztőktől származik. Meghatározzák a kísérleti folyamat helyét.
3. Felhasználók és telepítési helyek előkészítése		A felhasználói képzést - teszt résztvevők végzik. A telepítési hely elkészül.
4. A tapasztalt verzió telepítése		A tapasztalt verzió telepítve van, és szerepel a munkában.
5. A tapasztalt verzió támogatása és ellenőrzése		A felhasználók és a rendszer munkájának ellenőrzése, a működési segítségnyújtás, a rendszer működéséről szóló információk gyűjtése
6. Visszajelzés a felhasználókkal és az eredmények értékelésével		A felhasználók véleményüket fejezik ki a rendszer működéséről, jelzik a hiányosságokat és hibákat.
7. Módosítások és kiegészítések	Az észlelt hibákat korrigálják, a változások a tervezésben vagy folyamatban vannak. Rögzített eredményeket biztosítanak a felhasználók munkájához és értékeléséhez.
8. A telepítésre vonatkozó döntések	Ha a tapasztalt tesztelés munkájának eredményei megfelelnek a felhasználóknak a rendszer telepítéséről.

3.2 Alkalmazás telepítési módszer

Ebben a szakaszban a fejlesztő (vagy csapat) telepíti a megoldás megoldásához szükséges technológiákat és alkatrészeket, a projekt a kíséret és a támogatás szakaszába kerül, és az ügyfél végül jóváhagyja. A telepítés után a parancs értékeli a projektet és a felhasználói felmérést, hogy megtudja az elégedettségük mértékét.

Telepítési szakasz célkitűzései:

¾  Az oldatot az ipari környezetre átadja;

¾  Az ügyfél elismerése a projekt befejezésének ténye.

Az egyes telepítési helyszínre jellemző alkatrészek bevezetése több szakaszból áll: előkészítés, telepítés, képzés és hivatalos jóváhagyás.

A rendszerbeállítási fázis eredményei Escort és Támogatási rendszerek, dokumentumtár, ahol a projekt során kifejlesztett dokumentumok és kódok összes verziója kerül elhelyezésre.

A fejlett rendszer telepítéséhez cselekvési tervet készítettek el, amelyet a 3.1. Táblázat tartalmaz.

3.1. Táblázat - Alkalmazás telepítési terv

törvény	A cselekvés leírása
1. Biztonsági mentés	A felhasználói adatok biztonsági mentése a részvételével és a koordinációval történik, az információ átvételével a cserélhető médiára (CD, DVD)
2. A megoldás alapvető összetevőinek beállítása	A megoldás működését biztosító technológiák alkalmazása. Ebben az esetben a Visual FoxPro komponens telepítése
3. Ügyfélalkalmazás telepítése	Transzfer a felhasználó számítógépére, és állítsa be a fejlett és adatbázis végleges verzióját
4. Képzés	A felhasználói képzés a rendszerrel való együttműködésre kerül, a fejlesztő meg van győződve az ügyfelek munkájának helyességéről és megértéséről
5. A projekt kliens tudásbázisának átadása	Az ügyfél minden projektdokumentációt továbbít
6. A projekt lezárása	A projekt lezárásáról szóló jelentést készítenek. Az ügyfél jelzi az elfogadási aktust.

A normál működés érdekében aws a Microsoft WindowsXP operációs rendszert igényel.

4 Információs projektmenedzsment

4.1 A fejlesztési életciklus kiválasztása

Az IP-tervezési módszertan egyik alapvető koncepciója a szoftver életciklusa (LCC szoftver) fogalma. Az LCC folyamatos folyamat, amely a döntés meghozatalának pillanatában kezdődik, hogy megteremtse és véget érjen a teljes lefoglalás időpontjában.

A fő szabályozó dokumentum szabályozza a LCH szoftver a nemzetközi szabvány az ISO / IEC 12207 (ISO - Nemzetközi Szabványügyi Szervezet - International Organization for Standardization, IEC - Nemzetközi Elektrotechnikai Bizottság Műszaki - Nemzetközi Bizottság Villamosmérnöki). Meghatározza az Elc-struktúrát, amely olyan folyamatokat, műveleteket és feladatokat tartalmaz, amelyeket a szoftver létrehozása során kell elvégezni.

Az ISO / IEC 12207 szabvány nem kínál konkrét LC modellt és szoftverfejlesztési módszereket. A ZHC modell alatt megértheti azt a struktúrát, amely meghatározza az LCC folyamatok, műveletek és feladatok végrehajtásának és összekapcsolásának sorrendjét. Az LCD-modell az IC sajátosságaitól és a létrehozás és a funkciók feltételeitől függ.

A mai napig számos modell van a szoftver életciklusának, de két modell a legnépszerűbb és elosztva:

Spirális modell (lásd 4.1 ábra);

Iteratív modell.

4.1 ábra - Spirál modell LC

Információs rendszer létrehozása, azaz "A Warehouse Munkavállalói nagykereskedelmi alap" automatizált munkahelye ", ez az iteratív volt. Az iteratív modell megkülönböztető jellemzője hívható, hogy ez formális módszer, amely sorozatban végzett független fázisokból áll, és gyakori felülvizsgálatra van szükség (4.2. Ábra). Az iteratív megközelítés bebizonyította magának az IP-et, amelyre a fejlesztés kezdetén határozottan és teljes mértékben megfogalmazhatják az összes követelményt annak érdekében, hogy a fejlesztők szabadon legyenek, hogy a lehető legnagyobb mértékben megvalósítsák őket a technikai ponttól Kilátás.

Az iteratív modell előnyei:

a modell jól ismert a fogyasztók számára, akik nem kapcsolódnak a szoftverfejlesztéshez és a végfelhasználókhoz.

A használat kényelme és egyszerűsége, mert Minden munkát szakaszban végzik (a modell fázisai);

A követelmények stabilitása;

A modell megértésre áll;

A modell szerkezetét még gyengén előkészített személyzet (tapasztalatlan felhasználó) vezetheti;

A modell nehézségekbe ütközhet és jól működik azoknak a projekteknek, amelyek meglehetősen érthetőek;

A modell hozzájárul a szigorú ellenőrzési projektmenedzsment végrehajtásához;

Megkönnyíti a projektmenedzser munkáját a fejlesztő csapat tervének és konfigurációjának előkészítéséhez.

4.2 ábra - iteratív modell ZHC

Fázisok modell:

Az elemzési szakaszban azon funkciók, amelyeket a rendszernek végre kell hajtania, azonosítja a legtöbb prioritást, amely előírja a kidolgozást, amely elsősorban az információs igényeket írja le;

A tervezési szakaszban a rendszerfolyamatokat részletesebben tartják. Elemezték, és szükség esetén funkcionális modellt kell beállítani. Rendszer prototípusok épülnek fel;

A végrehajtási szakaszban van egy rendszerfejlesztés;

A végrehajtási szakaszban a késztermék bevezetésre kerül a már jelenlegi szervezeti rendszerbe. A felhasználók képzettek;

A kísérőlap szakaszban a szoftver termék karbantartása (bármilyen kiegészítés vagy változás, több funkcionális termékmûködés).

A szoftverfejlesztési életciklus modellje fontos lépés. Ezért a projekt esetében a szoftverfejlesztési modell kiválasztása a következő folyamatok használatakor végezhető el.

Az asztalokba helyezett projekt megkülönböztető kategóriáinak elemzése.

Válaszoljon az egyes kategóriákra felsorolt \u200b\u200bkérdésekre az "igen" és "nem" szavak hangsúlyozásával.

Keresse meg az egyes kategóriákhoz kapcsolódó kategória vagy kérdések kategóriáját a projekthez képest, amelyhez elfogadható modell van kiválasztva.

Fejlesztői csapat . A lehetőségek alapján a fejlesztő csapat személyzetének kiválasztása a pillanat előtt a szoftverfejlesztési életciklus modelljét választja. Az ilyen csapatok jellemzői (lásd a W. függelék W.1 táblázat) fontos szerepet játszanak az életciklus modelljének kiválasztásában, ami azt jelenti, hogy a csapat jelentős segítséget nyújthat a szoftver termék életciklusának modelljének kiválasztásában, mivel Felelős az életciklusfejlesztési modell sikeres végrehajtásáért.

Csapatcsapat . A projekt kezdeti szakaszaiban teljes képet kaphat a felhasználók csapatáról (lásd a Függeléket és az 1. táblázatot), amely a fejlett szoftverrel és jövőbeni kapcsolattal fog működni a fejlesztő csapatával a projekt során. Az ilyen prezentáció segít a megfelelő modell kiválasztásának, mivel egyes modellek megkövetelik a fejlesztési folyamat fejlesztése és tanulmányozása során, mivel a követelmények kissé megváltoztathatják a felhasználót a fejlesztési folyamat során, a fejlesztőnek ismernie kell ezeket a változásokat és hogyan Ezek a változások a szoftverben vannak.

4.2 A program projekt céljának és területének meghatározása

A programterméket az állományban lévő árukon fejlesztették ki, lehetővé téve, hogy automatizálja a termékadatok átvételének, strukturálásának és tárolásának folyamatát, valamint egyszerűsítse a jelentések kibocsátásának folyamatát.

A program projekt célkitűzései a termékszámlázási rendszer létrehozása és telepítése. Ezt a rendszert a "Cleonelly" személyzet belső használatára tervezték, a legtöbb esetben a vállalati raktár munkatársai.

A szoftvertermék hatókörének meghatározásához az alábbiakban ismertetjük, ami nem lehet szoftverprojekt.

A program projektnek:

Belső használatra a szervezetben;

Projekt a multiplayer hozzáférés végrehajtására;

Olyan projekt, amely képes a vállalkozás termékével kapcsolatos információk bővítésére, megváltoztatására és tárolására;

Olyan projekt, amely képes engedélyezni, megváltoztatni és tárolni a rendszerhasználók tájékoztatását;

Olyan projekt, amely képes engedélyezni, megváltoztatni és tárolni az ügyfelek és beszállítók közötti információkat, amelyek a kötött ügyletek tárgyát képezik;

Egy olyan projekt, amely végrehajtja a külső jelentések kialakulását.

4.3 A művek működési listájának kialakítása

Egyedi termék vagy szolgáltatás (projekt eredmény) létrehozásához szükség van bizonyos munka sorrendjének elvégzésére. A projekt tervezési feladata pontos pontos pontos a végrehajtási idő és a költségek költsége. Pontosabban, az értékelés megadása, annál nagyobb a projekt tervének minősége. Ahhoz, hogy pontos értékelést adjon, meg kell mutatnia a projekt munkájának összetételét, vagyis meg kell tudnia, hogy melyik dolgot kell teljesítenie. Csak a tervezési munka listája után készült, az egyesek időtartama becsült, és a végrehajtásukhoz szükséges erőforrások kiosztásra kerülnek. És csak akkor becsülheti meg az egyes feladatok végrehajtásának költségeit és időzítését, valamint a kiegészítés eredményeként a projekt teljes költségét és időszakát. Ezért a munka összetételének meghatározása az első lépés a projekt tervezésekor. A tervezési munka meghatározása a projekt szakaszai (vagy fázisai) meghatározásával kezdődik. Például a projektben a "raktárkészlet" fázisok létrehozása kiemelhető:

Szoftverkövetelmények kidolgozása;

Design információs rendszer;

Az információs rendszer végrehajtása és tanúsítása;

Rendszer végrehajtása.

A fázisok összetétele és eredményeik meghatározása után meg kell határozni ezeknek a fázisoknak a sorrendjét egymáshoz képest, és a végrehajtás határidejét. Ezután meg kell határoznia, hogy mely fájlokból állnak egy fázisból, amelyben ezek a munkák végeznek, és mikor kell teljesíteni, ha végrehajtásra kerülnek.

A munkák megnyitó listáját (4.3. Ábra) olyan szoftvertermék segítségével tervezték, mint a MS Project 2003.

4.3 ábra - A munkák ajánlott listája

4.4 A fejlesztés időtartamának és költségének értékelése

Időtartam értékelése. A munkálatok megnyitó listájának megteremtése után határozható meg (4.3. Ábra, 4.3. Bekezdés). Ez az időtartam becslése a GANTA-chart (K alkalmazás) segítségével látható.

A diagramok a projektfájlban található információk grafikus megjelenítése. A diagramokból a feladatok sorrendjét, a relatív időtartamukat és a projekt egész időtartamát kaphatja.

A GANTT-diagram az egyik legnépszerűbb módja a projekt tervének grafikai bemutatásának, amelyet számos projektmenedzsment programban használnak.

Az MS projektben a GANT Diagram a projektterv vizualizálásának fő eszköze. Ez az ábra egy olyan grafikon, amelyen az időskála vízszintesen helyezkedik el, és a feladat függőlegesen helyezkedik el. Ebben az esetben a feladatokat jelző szegmensek hossza arányos a feladatok időtartamával.

A szegmensek melletti GANNA-diagramon további információk jelenhetnek meg (a bevont erőforrások nevei és letöltése megjelenik a feladat során).

A költségek becslése

A projekt a feladatok , Vagyis az egyes eredmények elérésének célja. Hogy a feladat elvégezhető rajta erőforrások .

Az erőforrások fontos tulajdonsága a projektben való használatuk költségei (költség (költségek)). Az MS projektben kétféle erőforrásköltség van: időalapú árfolyam és felhasználási költség.

Az időalapú ráta (arány) az időtartamonkénti erőforrás felhasználásának költségein fejeződik ki, például 100 rubel / óra vagy 1000 rubel naponta. Ebben az esetben az erőforrás-részvétel költsége a projektben lesz az az idő, amely alatt a projektben dolgozik az óradíj megszorozódása.

Ebben az esetben egy időalapú rátát használtunk (4.4. Ábra) Az erőforrások felhasználásának teljes költsége a 4.5. Ábrán látható.

4.4. Ábra - időalapú árfolyam az erőforrás használatában

Ebben a képen látható, hogy a projekt teljesítése során a rendszer fejlesztője 50 rubelt kap óránként; Az üzleti elemző óránként 45 rubelt kap, a teszter 38 rubel / óra. A túlórát nem veszik figyelembe.

4.5 ábra - Az általános költségek a projektforrások használatához

4.5 A projektforrások forgalmazása

A "számviteli raktárkészlet" rendszerének forrásának töredéke a 4.6 ábrán látható

4.6 ábra - A projektforrások forgalmazásának töredéke

A projektben végrehajtott egyes munkák esetében az erőforrást összehasonlítjuk a munka elvégzéséhez. Az ábra a munkaerőköltségek teljes számát mutatja az egyes források és az adott napon töltött órák meghatározott számát.

4.6 A projekt gazdasági hatékonyságának értékelése

A projekt gazdasági hatékonyságának kiszámítása fontos lépés. Itt van kiszámolják a projekt gazdasági hatékonyságát. Ez a számítás megmutatja, hogy a projekt mennyire előnyös, vagy a projekt teljesen veszteséges. A projekt gazdasági hatékonyságának kiszámításakor szükség lesz a projekt megtérülési ideje kiszámításához. A megtérülési időszak megmutatja azt az időszakot, amelyre a projekt kifizeti.

Beviteli adat.

További nyereség a projekt megvalósításából (DP) \u003d 38000 rubel. További nyereséget a vállalati szakértők előrejelezték.

A beruházások indítása (IC) \u003d 39396,47 rubel. A kiindulási beruházások megfelelnek a projektforrások felhasználásának teljes költségének (4.5. Ábra a 4.6. Bekezdés)

Diszkontráta (i) \u003d 12%.

A projekt kiszámításának határideje (n) \u003d 2 év.

További nyereség a projekt megvalósításából (DP) \u003d 38000 rubel.

A projekt végrehajtásának éves költsége (Z 1) \u003d 15 000 rubel.

Éves projekt végrehajtási költsége (Z 2) \u003d 10 000 rubel.

Éves pénzbevételek (R 1) \u003d 23000 rubel.

Éves készpénzbevételek (R2) \u003d 28 000 rubel.

Értékelésekor beruházások, a vonatkozó számítási módszert nettó jövedelem szerepel használunk, amely magában foglalja a diszkontálás pénzáramok: az összes bevétel és a költségek kapnak egy időben.

A vizsgált módszer központi mutatója az NPV (nettó jelenérték) - a cash flow jelenlegi értéke. Ez az abszolút mérésű befektetési tevékenységek általános eredménye.

Fontos szempont a választás a diszkontrátát, amelynek tükröznie kell a várható átlagos hitel százalékos szintet a pénzügyi piacon.

A tiszta csökkentett jövedelem (NPV) a 4.2 képlet alapján kerül kiszámításra

(4.2)

R k - Éves pénzbevételek Név alatt.

k - Az évek száma, amennyire a projekt kiszámítása.

IC - A befektetés elindítása.

i - diszkontráta.

A képlet számításai szerint NPV \u003d. 3460,67 rubel.

Az NPV mutató abszolút növekedés, mivel értékeli, hogy a jövedelem átfedi a költségeket. Mivel az NPV\u003e 0, a projektet meg kell tenni.

A befektetési visszaadási arányt (ROI) a 4.3 képlet alapján számítjuk ki

(4.3)

A számítások (ROI) \u003d 108,78%

4.1. Táblázat  A megtérülési időszak tervezetének kiszámítása

= 1,84

Visszafizetési időszak n ok \u003d 1,84 év (1 év és 11 hónap)

Mivel a ROI \u003d\u003e 100% (nevezetesen \u003d 108,78%), a projekt nyereségesnek tekinthető.

(4.4)

Így a jövedelmezőségi index egyenlő (PI) \u003d 1.2

Automatizált munkahelyek

A funkcionális jellemzőkre vonatkozó követelmények

A generált jelentések listája

4.4.2. A tervezési és irányítási rendszer követelményei

Az információs rendszernek biztosítania kell a vállalati erőforrások tervezését és a bypass termelés kezelését.

Az IP-funkcionalitás követelményei:

1. A késztermék konfigurációjának kezelése (GP):

A GP összetételére vonatkozó szabályozási információk fenntartása azzal a lehetőséggel, hogy meghatározzák a specifikáció relevanciájának időtartamát, és a GP termelésének több különböző specifikációval történő megállapításának lehetőségével;

A GP-ben szereplő gyártóeszközök technológiájáról szóló szabályozási információk fenntartása a technológiai relevancia időtartamának meghatározásának lehetőségével és annak lehetőségével, hogy több különböző technológiával megtalálja a GP termelését;

2. Értékesítési menedzsment:

Az ügyfélkapcsolatok történetének megtekintése;

Az Ügyfél alkalmazásának nyilvántartása / kiigazítása a GP, a mennyiségek, a szállítási dátum, az eladási ár és a további feltételek listájának megjelölésével;

A GP által megrendelt jelenlegi gazdasági mutatók (számítás) megtekintése;

3. Termelési tervezés:

A rendelkezésre állásfoglalási ütemterv képzése A tervezett időszak minden napján rendelkezésre álló normális órák számát jelzi;

A gyártási terv kialakulása a gyártott termék, annak számát, a használt felszerelését, a tervezett időszak minden napján;

Az anyagok és alkatrészek gyártására vonatkozó terv kialakítása;

A létrehozott termelési tervek rakodási berendezéseinek ellenőrzése és kezelése;

A végrehajtás során módosítsa a termelési tervbe;

A termelési terv gyári elemzése;

4. Termelési menedzsment:

Cserélhető feladatok (ruhák) kialakítása a termékek gyártásához;

Az előadók felszerelésének célja / áthelyezése és a kiadott termékek számának megjelölése, a hibás termékek száma és a házasság okai;

Az árucikk értékeinek tárolása és mozgása (TMC) a termelésben;

5. Ellátási menedzsment:

A beszállítói kérelmek, a beszállító feltüntetésével, a TMC nómenklatúrája, a TMC nómenklatúrája, a kínálat száma és határideje;

A vásárlás iránti kérelmek képződése a TMC-re vonatkozó egyszeri megrendelések alapján;

A vásárlási alkalmazások végrehajtásának nyomon követése és nyomon követése;

A maradékanyagok működtetése;

Terv-tényelemzés az ellátás;

6. Költséggazdálkodás:

A GP tervezett (szabályozási) költségének kialakulása;

A termelés tényleges költségeinek rögzítése;

A GP tényleges költségeinek kiszámítása;

Terv-tény-költségelemzés.

A megrendelés szabályozási költségének kiszámítására vonatkozó követelmények

A termék szabályozási költségét és a teljes megrendelést a következő eljárás szerint kell kiszámítani:

(1) A termék szabályozási költségeinek közvetlen anyagösszetevője az e termék (előírások) szabályozási keretéről szóló információk alapján (előírások) és a jelen leírásban szereplő TMC számviteli árak alapján alakul ki. A specifikáció esetében számos anyagköltség használata megengedett.

2. A közvetlen bérek értékét a termék szabályozási teljesítménye alapján kell kiszámítani. SET: Az egyes műveletek szabályozási időtartama, a művelethez szükséges munkavállaló szakma, valamint a munkavállaló mentesítése. Továbbá a rendszert a munkavállalók és azok kibocsátásának szokásos szokásos szokásos pénzállománya vezetik be.

3. A közvetett költségek szabályozási értékét a megadott bázis százalékos aránya (a közvetlen költségek e cikk szerinti értékeinek értéke).

A számítás végrehajtása érdekében az alábbi adatrendszerben kell megadnia az alábbi adatokat:

1. A termék gyártásának előírása (valamint az e termékben szereplő félkész termékek valamennyi partnerének gyártásának előírásai);

2. A termékgyártási technológia és a félkész termékek benne szerepelnek: Milyen műveleteket kell kitölteni és mikor kell kitölteni. Ezenkívül minden műveletet a szakma és a végrehajtáshoz szükséges munkavállalók (az adott termék felszabadításához) szükséges munkavállalók teljesítése;

3. A felhasznált TMC számviteli árak jegyzőkönyve;

4. A normo órák készpénzaránya a szakmákhoz és a kibocsátásokhoz.

A tényleges megrendelés költségének kiszámítására vonatkozó követelmények

A termék tényleges költségét és a teljes megrendelést a következő eljárás szerint kell kiszámítani:

(1) A termékek gyártásának közvetlen anyagköltségeit a termelési átalakításra vonatkozó anyagok műhelyének kiadásairól szóló tényleges adatok alapján számítják ki. Ugyanakkor a termékben szereplő összes félkész termék értékét kiszámítják. Az összegbecslés a vállalat számviteli politikájában elfogadott módszertan szerint történik.

2. A közvetlen termelési munkavállalók fizetését a workshopok bezárására vonatkozó adatok alapján számítják ki. Abban az esetben, ha a vizsgálati időszakban szereplő ruhák elszámolása nem történik meg, a fizetés az elosztandó közvetlen költségekre utal, azaz. Egy bizonyos adatbázis szerint a kiadott termékekre osztja.

3. A közvetlen gyártóberendezések értékcsökkenését a közvetlen kiadások összetételében tartalmazza, ha az ezen határon használt berendezés (gép) minden egyes átalakítóra van megadva.

4. Az elosztandó közvetlen költségek:

Az egyes átalakításnál kevésbé fogyasztott fő anyagok (például olyan vegyi anyagok, amelyeknek a termelési egységenkénti normája olyan kicsi, hogy értelme, hogy ezt a normát is figyelembe vegye a pecsétüket);

A munkavállalók bérei a campeagly elosztására vonatkozó információk hiányában;

A közvetlen felszerelések értékcsökkenése csak az összes havi összege esetében az újraelosztás felett.

Az ilyen ráfordításokat a kiválasztott elosztási bázis szerint (például a közvetlen anyagköltségek arányában) osztják el.

1. Védőköltségek (25 számla BU): a kiválasztott elosztási bázissal arányos termékekre vannak elosztva. Az ilyen kiadások aránya továbbra is fennmaradhat, vagy sem a vállalaton elfogadott számviteli politika szerinti hiányos termelés összetételében.

(2) Az általános költségek és értékesítési költségek (26 és 44 számlák BU) a jelenlegi időszak költsége, és a végrehajtás kiadásaira vonatkozik. Az ilyen költségek eloszlása \u200b\u200ba késztermékek költségeihez külön jelentéssel láthatók.

Információs rendszer teljesítmény követelményei

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

A megbízhatóság követelményei

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

Az információs rendszer megbízható (fenntartható) működésének biztosítása

Az információs rendszer megbízható (fenntartható) működését biztosítani kell a szervezeti és technikai intézkedések halmazának, amelynek listája az alábbiakban látható:

1. A megszakítás nélküli tápegység megszervezése;

2. licencelt szoftverek használata;

3. Rendszeres teljesítése ajánlásait a Munkaügyi Minisztérium és a társadalmi fejlődés, az Orosz Föderáció, meghatározott döntése július 23. 1998. „On jóváhagyása ágazatközi modell szabványok időt dolgozik szolgáltatás fenntartása PEVM és irodai berendezések és támogató szoftverek ";

4. A GOST 51188-98 követelményeinek rendszeres teljesítése. "Az információ védelme. Számítógépes vírusok tesztelése ";

5. Az információs rendszer adatbázisának rendszeres fenntartása az információs rendszer útján vagy az adatbázis-kezelő rendszer eszközével.

1. Relevancia és kutatás szükségessége

A közelmúltban az új ingatlankezelés oroszországi Szövetségének megjelenésével a lakás tulajdonosának (HOA) tulajdonosa formájában, a lakhatási tulajdonosok (Hoa - Lakeowners Ashotiations) és társasházak (később - ingatlankezelési szervezetek) a bérlők (A tulajdonosok) a lakhatás megjelent a lehetőséget, hogy befolyásolja a bérlők (tulajdonosok) az ingatlanok fenntartása minőségét, a szomszédos terület javítását és bizonyos mértékig a közművek költségeit.

Az Orosz Föderáció lakáskódexének 161. cikkével összhangban egy lakóépület irányítása biztosítani kell a polgárok kedvező és biztonságos életkörülményeit, a közös tulajdon megfelelő karbantartását egy lakásépítésben, a megadott ingatlan használatának megoldása, valamint az ilyen házban élő állampolgárok számára nyújtott segédeszközök biztosítása.

b) Oktatási folyamat

Tudományos és oktatási tanfolyamok fejlesztése, valamint tudományos és népszerű anyagok

	A tantárgy neve/ anyag	Rövid leírás/ anyag
Tudományos és oktatási tanfolyamok	Tutorial "Információs rendszerek kezelése az apartmanházak"	Az Orosz Föderációban és külföldön használt ingatlankezelési információs rendszerek funkcionalitása. A funkcionális funkciókat összehasonlítjuk az információs rendszer kiválasztására vonatkozó ajánlásokkal. Ajánlott: 080100.62 "Economics" és 080500.62 "Business-Informatika" területén a diákok edzésére
Laboratóriumi műhely "Az MKD menedzsmentszervezet üzleti szabályzási rendszere"	Lépésről lépésre az üzleti szabályok kezelési modul létrehozására az IBM ILOG segítségével. A HOA üzleti szabályainak kezelésére szolgáló algoritmus. Úgy tervezték, hogy a diákokat 080500.62 "üzleti informatika" irányába vonja
Laboratóriumi műhely "Az ingatlankezelő szervezetek többségi modellezése"	Lépésenkénti utasítások az ügynökök kialakulásához és az ingatlankezelő szervezet modell kialakításához Anylogic segítségével. Úgy tervezték, hogy a diákokat 080500.62 "üzleti informatika" irányába vonja
Tutorial "Egy apartmanház alkotó adatbázisának fejlesztése MS Access 2010 DBMS"	Az adatbázis táblázatok kialakításához lépésről lépésre vonatkozó utasítások vannak, amelyek összekapcsolják őket, építkezési formanyomtatványokat, kérelmeket, jelentések és makrókat az MS Access 2010 DBMS képességekkel.
Laboratóriumi műhely "Az ingatlankezelés üzleti folyamatainak elemzése"	Az objektumorientált UML modellezési nyelv használatával tervezett ábrák adhatók meg. Ajánlott: 080100.62 "Economics" és 080500.62 "Business-Informatika" területén a diákok edzésére
Tudományos népszerű anyagok	Monográfia "A régió szervezeteinek gyári és klaszter elemzése az ingatlankezelés területén"	Ajánlások a HOA kiválasztott régió jellemző paramétereinek tényezőjének és klaszterelemzéséről. Információk az ingatlankezelő szervezetekről, amelyek ugyanazon üzleti folyamatokkal rendelkeznek, és meghatározzák a tevékenységüket érintő fő tényezőket
Monográfia "Információs csere algoritmusok az ingatlankezelő szervezetben"	Az általános algoritmus munkájának a VI az algoritmusok működésének szoftver modulok végrehajtására információs szolgáltatások az előfizetők az algoritmusok a kölcsönhatás szoftver modulokat kapnak. Az információs rendszer felhasználói felülete. A szoftverkód modulok fejlesztésének jellemzői az MS Visual 2010 fejlesztési környezetével
Cikk "Az előfizetők és információs rendszerek osztályozása az MKD menedzsmentszervezetekben"	Az információcsere az ingatlanmenedzsment szervezésén belüli információ mintái, az információcsere becsült összetétele és mennyisége az információcserében, az állítólagos adatátalakítás az információcsere során, a bemeneti és kimeneti adatok benyújtásának formája
Cikk "A HOA modellezési modelljének többéves utánzási modelljének fejlesztése"	Megközelítések az ügynökök kialakulásához a téma területén, valamint egy szimulációs modell fejlesztését. A HOA modellezési tevékenységeinek eredményei különböző forrásadatokkal rendelkeznek.
Cikk "A HOA üzleti szabályainak kialakítása"	Megközelíti az üzleti szabályok kialakulását. Az IBM ILOG-t használó üzleti szabályok irányítási rendszerének megvalósításának lehetőségeit figyelembe veszik. Példa a döntés meghozatalára vonatkozó üzleti szabályok használatára.
Cikk "Az algoritmusok kialakulása az ingatlankezelés információs rendszeréhez"	A szerkezet az algoritmus az információs rendszer, a szerkezet algoritmusok szoftver modulok végrehajtása információs szolgáltatások és az információcsere a szervezet adatbázis tekinthető.
	Cikk "Holisztikus megközelítés alkalmazása a HOA tevékenységeinek összetett kulcsfontosságú teljesítménymutatóinak kialakításához"	A rendelkezések alkalmazása holisztikus szemlélet kialakulásához komplex mutatók létrehozását lehetővé tevő értékelési rendszer megvalósítása a stratégiai és taktikai (működési) célokat a szervezet az ingatlangazdálkodás, állapotának értékelése a szervezet és ellenőrzése Figyelembe kell venni az információs rendszer előfizetőinek üzleti tevékenységét valós időben.
Cikk "Információs szolgáltatások az apartmanok kezelésére"	A külföldi információs rendszerek által nyújtott információs szolgáltatások az ingatlanok tulajdonosai (bérlők) az apartmanházakban szerepelnek.
Cikk "Adatbázis létrehozása az információs rendszerhO HOA"	Adatmodellek, adatok tárolási és feldolgozási technológiája, adatkompozíció, adatformátumok a felhasználói felületek és a kimeneti dokumentumok, adattípusok, táblázatok tervezett összetétele, valamint az asztalok közötti áramköri kapcsolatok
Cikk "A HOA üzleti folyamatainak szervezeti elemzése és modellje"	A modellek komplexumának fejlesztése: a cél-beállítás, a szervezeti és funkcionális modell stratégiai modellje, a funkcionális-technológiai modell, a kvantitatív modell, az adatstruktúra modell (milyen formában a rendeletek a HOA-t és a külső környezet tárgyát írják le), az üzleti folyamatok

A kifejlesztett információs rendszer hozzárendelése alapján tovább fogjuk tervezni az alkalmazás moduláris felépítését. A moduláris szerkezet meghatározásához az UML 2.0 jelzőrészek ábráját használjuk (3.4. Ábra).

Ábra. 3.4.

Az információs rendszer három összetevőből áll:

• 1. Interfész. A felhasználói interakció végrehajtása az információs rendszerrel. Tartalmazza a következő modulokat:
  • · Bevezetés / Kimenet - Információ beírása és visszavonása IP-vel dolgozik;
  • · Jelentés a jelentéstétel szervezése a személyzeti ügynökség különböző területeiről szóló dokumentációs formákkal összhangban;
  • · Keresés - a jelöltek és üres álláshelyek keresése a megadott paraméterekhez;
• 2. Adatfeldolgozás. Információs feldolgozási funkciók végrehajtása: Adatok keresése az adatbázisban, matematikai modell a dokumentumok elsődleges elemzésének és stb.
• 3. DB. Az ügyféladatokat tartalmazó adatraktár végrehajtása.

Az adatbázis-struktúra fejlesztése

Amint korábban említettük, az információs rendszerben az összes információt egyetlen adatbázisban tárolják. Az adatbázis logikai szerkezetének szimulálásához az IDEF1X módszertant alkalmazták. E módszertan szerint az információs modell kiépítésének folyamata a következő lépésekből áll:

• · Az entitások meghatározása; az entitások közötti szervezetek meghatározása;
• · Elsődleges és alternatív kulcsok beállítása;
• · Az entitások attribútumainak meghatározása;
• · A modell meghatározása a normál forma kívánt szintjére;
• · A modell fizikai leírásához való áttérés: A levelezés célja A gazdálkodó egység neve a táblázat neve, az entitás attribútuma - az asztal attribútuma;
• · A triggerek, eljárások és korlátozások beállítása;
• · Adatbázis-generáció.

Diagram Essence-Bond leírja az adatbázist az IDEF1.x kifejezések három fő blokk - entitások, attribútumok és kapcsolatok. Ha figyelembe vesszük a diagramot a tárgykörének rendelkezéseinek grafikus ábrázolására, az entitások és az attribútumok főnevek, és a linkek igék.

Mivel a jövőbeli ICS ezen az adatbázisban keres, az alábbiak a dokumentum fő attribútumaiként vannak kiválasztva:

• - dokumentum neve;
• - a dokumentum kézhezvételének időpontja az archívumba (az archiválási szolgáltatásokat végrehajtó ügyvédi vállalkozásokat követi a dokumentáció tárolási ideje. Minden dokumentumnak saját eltarthatósága van. Sok értékpapír az idő múlásával elveszíti relevanciáját, és értékük csökken nullára. Az ilyen dokumentumokat meg kell pusztítani. Az ilyen dokumentumok időben történő kiválasztását és a dokumentumok megsemmisítését az ügyvédi irodák által nyújtott archív szolgáltatások csomagjában foglalják magukban. Amikor az egyes dokumentumok tárolása után külön vizsgálatot végeztünk, az eltarthatósági idő meghatározandó. Ezen időszak után a dokumentumot pusztításra benyújtják);
• - a dokumentum tartozéka (típusa) (mivel az összes dokumentumot 7 fajra osztották, amelyekre a rangsor fontos);
• - oszlop;
• - ezredszám;
• - Salazki szám (ezek a 3 paraméter szükségesek az archívumban szereplő dokumentum helyének meghatározásához);
• - Egy dokumentum jelenléte a sejtben (meg kell ismernie az archívumban lévő dokumentumot, vagy a barátnak adja ki).

Az egyik ügyfélhez tartozó összes dokumentum kiválasztására vonatkozó kérelemnek ezt kell kineveznie. 3.5. Ábra. A benyújtott példában a dokumentumok száma 20-ra volt korlátozva.

Most tekintsd részletesebben a 3.6 ábrán bemutatott fejlett információs rendszer logikai adatmodelljét.

Ábra. 3.5

Ábra. 3.6.

A bemutatott adatmodellből világos, hogy három entitást tartalmaz az attribútumok halmazával, és közülük kettő függ, és az egyik nem.

A munkavállalói lényeg, amely független entitással rendelkezik attribútumokkal:

• · Munkavállalói azonosító szám - ennek a gazdálkodó egységnek az elsődleges kulcsa;
• · TELJES NÉV;
• · A specializáció területe;
• · Értékelés;
• · További információ.

Az "ügyfél" lényege a "munkavállaló" entitásának függő lényege, amely azt jelzi, hogy minden munkavállaló sok ügyfelet tud szolgálni. Az ügyfél lényege tulajdonságai vannak:

• · Sorozat és útlevélszám - ennek a gazdálkodó egységnek az elsődleges kulcsa;
• · Munkavállalói azonosító szám - a entitás másodlagos kulcsa;
• · TELJES NÉV;
• · A specializáció területe;
• · Értékelés;
• · További információ.

Az entitás "dokumentum" az "ügyfél" entitás függő lényege, amely azt jelzi, hogy minden ügyfél számos különböző dokumentumot tárolhat az archívumban. Az esszenciális dokumentum tulajdonságai vannak:

• · A dokumentumazonosító az entitás elsődleges kulcsja;
• · Series és útlevélszám - az entitás másodlagos kulcsa;
• · Dokumentum neve;
• · Az átvétel dátuma;
• · A csoporthoz tartozó tartozás;
• · Oszlopszám;
• · Polcok száma;
• · Salace száma;
• · A dokumentum jelenléte a sejtben.

Különböző modulokból készült tájékoztatási rendszer megengedte a Nizhny Novgorod Automobile Plant "Chaika-Service", hogy megvalósítsa a termelés eszméjét, a leginkább figyelembe véve azokat az ügyfelek kívánságait, akik megrendelésüket a vállalkozásban elhelyezték

A különböző modulokból létrehozott információs rendszer lehetővé tette a Nizhny Novgorod Automobile Plant "Chaika-Service", hogy megvalósítsa a termelés ötletét, a leginkább teljes mértékben figyelembe véve azokat az ügyfelek kívánságait, akik megrendelésüket a vállalkozás

A vállalat informatikai szolgáltatásainak fő feladata, a jelenlegi nehéz időben vezető vállalkozás, az, hogy csökkentse az informatikai költségeket, és olyan eszközöket biztosítson, amelyek vezetik a válság tesztelésének sikeresen leküzdésében. Tehát, Alexey Ghanin, a Nizhny Novgorod Automobile Plant IT osztályának vezetője, amely specializálódott a soros és egyedi autofektechnika előállítására.

A vállalat 2006-ban, amikor a régi növény tulajdonjogát megszerezték, és a második terület fejlődése megkezdődött. Természetesen a területek mindkét terület egyetlen információs területen történő kombinálásának feladata. A VPN hálózat létrehozásával kezdtük el, de amikor a felhasználók száma nőtt, a csatorna sávszélességét nem hagyták ki. Ezután a száloptikai kábelt a két terület között helyezték el.

A válság kezdetével a hálózati erőforrások szükségessége csökkent, ez lehetővé tette a vállalat távközlési infrastruktúrájának aktív berendezéseinek beszerzését. A költségcsökkentés egy másik jelentős forrása volt a kiszervezés elutasítása és az informatikai feladatok végrehajtása saját erejére.

Ezenkívül a vállalat optimalizálja az internetköltségeket, elemzi és korlátozza a forgalmat. A vállalat ágak vannak Krasnodarban és Moszkvában, az összes helyszín egy számozással rendelkező IP-hálózatra van kombinálva. És most ez a belső hálózat a vállalkozás belsejében, amely jelentősen gazdaságosabb, mint a hosszú távú telefonkommunikáció hívása.

A vezetéshez hamarosan megadott eszközök közül Ganin elsősorban a költségek kiszámításának rendszerét nevezte. Már kidolgozott, és általános globális célként szolgál - a költségek csökkentése. A termékköltség kifinomult kiszámítását a mérnöki adatkezelő rendszer alapján tervezik. Ez részletes és operatív információkat szolgáltat a költségekről (korábban számviteli adatok alapján számítottak). A vállalat elegendő összetett termékeket termel, csak a különböző módosításokkal rendelkező járművek véges változatai körülbelül egy és fél ezer. Természetesen a részletek, amelyekből megyek, két nagyságrenddel többet.

A számvitelből - a termeléshez

Az első lépés azon az úton, automatizálás megszerzése 2002-ben a termék „1C: Számvitel 6.0” és a CAPR rendszer „Iránytű” Askon. A következő lépés a termelési tevékenységek automatizálása volt. A társaság „Rarus NN” kérésre a vállalkozás kezdte adaptációja az ERP rendszer „1C: Kezelése a gyártó vállalkozás 8” ( „1C: UPP 8”), hogy az igények és sajátosságok a vállalat. A projekt célja az egységes adatbázis létrehozása és az összes üzleti folyamat irányításának végrehajtása egy egységes információs rendszer alapján. A megvalósításának döntő sikertényezője a vállalkozás legfőbb vezetésének azonnali támogatása volt - a főigazgató, amely kezdeményezte és támogatta a projektet minden szakaszában.

A termelési tevékenységek automatizálásakor különös figyelmet fordítottak a kijelző megfelelőségére a gyártási folyamat rendszerében. A végrehajtó csapat szakemberei részletes leírással rendelkező technikai feladatot fejlesztettek ki, melyik autót az ügyfélnek meg kell kapnia, és mi szükséges az egyes megrendelésekhez. A dokumentum bekerül a típusú autó, a modell listáját szükséges technológiai műveletek, azok sorrendjét, egy listát a szabályozási műveletek, stb Ez a megközelítés lehetővé tette egy vállalat számára az ügyfelek számára, mivel a technikai feladatokat a Kereskedelmi Osztály vezetők alakították ki, amely megpróbálta maximalizálni az ügyfél kívánságait, majd a feladatok termelésbe kerültek.

Az informatikai szakemberek a technológusokkal együtt kifejlesztették az ipari és technológiai térképek specifikációinak blokkját. A késztermékek előállítására szolgáló havi terv alapján az anyagok szükségességét egy bizonyos időszakra határozták meg, figyelembe véve a jelenlegi maradékokat. Mindez lehetővé tette, hogy kompetensen tervezze meg az ellátási osztály munkáját.

IT osztályú alkalmazottak kifejlesztettek egy modult az "1C: UPP 8" számára, hogy importálják a "fa" termékeket az iránytű rendszerből, amelyet a vállalati tervezők használnak. A munka algoritmusa kiderült, a következők: Az "iránytű" tervezési iroda fejleszti a rajzot, és létrehoz egy 3D-s modellt az objektum, majd a termék szerkezetét a kifejlesztett modulhoz importálják az ERP rendszerbe az importált adatokon alapul. Ha a tervezők módosítják a csomópontot, akkor ezek a változások automatikusan megjelennek az összes rendszerben.

Először is, amikor Ganin elismerte, ő és szakemberei önmagukban meg akarták készíteni a mérnöki adatkezelés rendszerét, de hamarosan kiderült, hogy az Appius cégcsoportja, egy "1c" partner, saját replikálható PDM-megoldást fejleszt megkapta az "1c: PDM menedzsmenttechnikai adatok" nevét).

Visszacsatolás

A következő feladat az volt, hogy működési visszajelzést kapjon a termelésből, fontos, mert a termék termelési ciklusa egy vagy két héttel elfoglalhat. Korábban a megrendelés állapota egyszerűen telefonon látható volt, most a vonatkozó információkat az információs rendszer segítségével kapják meg.

Ennek az irányban az első lépés a technikai megbízás állapotának ellenőrzésére szolgáló rendszer fejlesztése volt. Bizonyos termelési folyamatok megváltoztak, különösen az SC tisztek kötelesek jelentést adni az üzemeltető által elfogadott munkáról, és belépett az adatokról az ERP rendszerben. Ennek eredményeképpen a rendszer elkezdte megmutatni a termelési rendelés szakaszát a felelősségteljes személyek jelzésével, ez lehetővé tette a vezetők számára, hogy ügyfeleinknek az igazi információkat biztosítsák, hogy milyen szakaszban vannak megrendelésük, és amikor készen állnak.

A következő lépés a termelési tervezési modul bevezetése volt. Korábban a tervezést Excel, kellemetlen eszközökkel végeztük, a hibák gyakran történtek. A termelési tervezés ERP-modulja után a vezetők rendelkeznek a kapott technikai feladatok alapján kialakított tényleges adatokkal. Ez lehetővé tette, hogy gyorsan ellenőrizze az egyes webhelyek betöltését. Ennek eredményeképpen a termelési tervezés pontossága és hatékonysága nőtt.

Hamarosan szükség volt a termelési folyamatok állapotáról, különösen a leállásokról. Hogy oldja meg ezt a problémát, én olyan rendszert, amely lehetővé teszi, hogy nyomon kövesse a gyártás során folyamatok alapján vonalkódos: az egyes technológiai művelet, az egyes műszaki feladat és minden alkalmazottja hozzárendelt vonalkód, telepített terminálok ellátott vonalkódolvasó.

A gyártási folyamat most a következőképpen épül fel. A munka megkezdése előtt a dandártáborozó vagy munkavállaló közeledik a terminálhoz, olvassa a vonalkódot, a technikai feladat és a technológiai művelet vonalkódját. A rendszer szempontjából ez azt jelenti, hogy a munkavállaló megkezdte a munkát. A befejezése után a munkavállaló vonalkóddal megismétli.

"Ez egy univerzális megoldás, emellett, nem igényel a számítógépes műveltség munkáját, - Ganin jegyzeteket. "Az autó a termelés fő és legdrágább összetevője, a leállások csökkentése lehetővé tette a megrendelések végrehajtásának élelmezését." A vállalat egy kényelmes és egyszerű veszteség elemző eszköz: a rendszer működik, a rendszer automatikusan generálja a rendszer minden egyes járműre, amely lehetővé teszi, hogy nyomon, amikor a munka kezdődött ez az autó, mikor végül mennyi idő az autó csak állt vár egy másik működését. Ha a megengedett időt túllépték, az okok okai és az ilyen hosszú leállások elkövetők keresése. Ennek eredményeképpen az előadók személyes felelőssége javult.

Az "1C: UPP 8" vállalati szakemberek egy blokk tervezési egységet valósítottak meg a Design Office számára. A rendszerben létrehozott technikai feladatok a főtervezőnek jönnek, analizálják őket, elosztják őket a tervezőknek a tervezőkön keresztül, és meghatározzák az egyes feladatok idejét. Egy ilyen munka megszervezése adja a főtervezőt és a vezetőket, amelyek a megrendelések alapját képezik, a tervezési iroda munkaterhelési fokának nyomon követésére, és ez viszont lehetővé teszi a termelés és a tervezők gyártásának összehasonlítását és racionálisan Kiosztja a meglévő emberi és termelési erőforrásokat.

Az elvégzett munkákra vonatkozó adatok, amelyeket vonalkódokkal kaptak, adja meg a Végrehajtók fizetésének számítási egységét. A rendszer rögzíti a munka idejét, amely megkönnyíti a kimenet és a túlóra óra számítását. Mindez hozzájárul a gyors és pontos bérszámfejtéshez.

Fontos hangsúlyozni, hogy a vállalat a bővítési pályán ment

Az ERP rendszer alapkonfigurációja további blokkokkal, anélkül, hogy megváltoztatná a belső struktúráját. Lehetővé vált különösen a frissítések bármilyen probléma nélkül.

Kezeléséhez az archívumban tervdokumentáció a vállalat bevezette a rendszert „1C: PDM műszaki adatok” (fejlesztés Appius GK) és integrálta a „1C: UPP 8”. Az új termékek létrehozása mellett a mérnöki adatkezelő rendszert tervezik, hogy a termékek költségeinek pontosabb kiszámítására szolgáljon.

Többszörös integráció

Az Enterprise bemutatta a GPS-navigációt, hogy nyomon kövesse a hosszú távon áthaladó kínálati és haszongépjárműveket. Ez lehetővé teszi, hogy optimalizálja az útvonalakat, csökkenti az üzemanyagköltségeket, világosabban ellenáll az ellátás fegyelmével.

„Chaika-Service” azt tervezi, hogy a társult a videokonferencia-rendszer egyetlen hálózatban minden ága - két Nyizsnyij Novgorod és az egyik Moszkvában, Krasnodar és Naberezhnye Chelny. Így a döntéshozatali felső vezetés hatékonysága javul, és a pénzügyi és ideiglenes üzleti költségek jelentősen csökkentik.

"Azt is tervezzük, hogy" 1c: UKP 8 "-on alapul, hogy kölcsönhatásba lépjen a TCP forgalmi rendőrségével, a tranzitszámok előkészítésével és nyomtatásával, - Ganin jegyzetekkel. - Az összes adatot egyetlen tárolóhelyen csoportosítják - egy autó kártyát, ahol minden azonosító számát, színét, testszámát stb. Beírja, majd ezeket az adatokat a technikai feladatban használják, a PTS nyomtatásakor, Számok, tanúsítványok, fiókok Ez az integráció révén az ügyfeleknek a gazdálkodó a lehetőséget, hogy kész a TCP és tranzit számok mellett az autó, aminek köszönhetően lehetővé válik, hogy emelés autók figyelembe a közlekedési rendőrök.