1. A kutatás relevanciája és szükségessége

Azzal, hogy az Orosz Föderációban a közelmúltban megjelent az ingatlankezelés új formája, a lakástulajdonosok szövetsége (HOA), a lakástulajdonosi egyesületek (HOA) és a társasházak (a továbbiakban: ingatlankezelő szervezetek) formájában a lakásbérlők (tulajdonosok) lehetőség az ingatlanok karbantartásának minőségének befolyásolására, a szomszédos terület javítására és bizonyos mértékig a rezsiköltségekre.

Az Orosz Föderáció Lakáskódexének 161. cikkével összhangban egy bérház vezetésének biztosítania kell a polgárok számára kedvező és biztonságos életkörülményeket, a társasházban lévő közös tulajdon megfelelő karbantartását, az ingatlan használatával kapcsolatos kérdések megoldását, valamint közszolgáltatások nyújtása az ilyen épületben élő polgárok számára.

b) oktatási folyamat

Tudományos és oktatási kurzusok, valamint ismeretterjesztő anyagok fejlesztése

	A tantárgy neve/ anyag	A tanfolyam rövid leírása/ anyag
Tudományos és oktatási tanfolyamok	Oktatóanyag "Információs rendszerek lakóházak kezeléséhez"	Bemutatjuk az Orosz Föderációban és külföldön használt ingatlankezelési információs rendszerek funkcionális képességeit. Összehasonlítják a funkcionális képességeket, ajánlásokat fogalmaznak meg az információs rendszer kiválasztásához. A 080100.62 „Közgazdaságtan” és a 080500.62 „Üzleti informatika” irányú hallgatók oktatására szolgál.
Laboratóriumi műhely "Az MKD-t kezelő szervezet üzletszabályzatának irányítási rendszere"	Lépésről lépésre útmutatást ad az üzleti szabálykezelési modul IBM ILog segítségével történő felépítéséhez. Bemutatjuk a HOA üzleti szabályok kezelésére szolgáló algoritmust. A 080500.62 „Üzleti informatika” irányú hallgatók tanítására szolgál.
Laboratóriumi műhely "Egy ingatlankezelő szervezet tevékenységének többügynökös modellezése"	Lépésről lépésre útmutatást ad az ügynökképzéshez és az ingatlankezelés szervezésének modelljének kialakításához az AnyLogic segítségével. A 080500.62 „Üzleti informatika” irányú hallgatók tanítására szolgál.
Oktatóanyag "Adatbázis fejlesztése társasházhoz MS Access 2010 segítségével"	Lépésről lépésre útmutatást ad az adatbázistáblák létrehozásához, a köztük lévő kapcsolatok létrehozásához, űrlapok, lekérdezések, jelentések és makrók összeállításához az MS Access 2010 lehetőségeivel.
Laboratóriumi műhely "Egy ingatlankezelő szervezet üzleti folyamatainak elemzése"	Bemutatjuk az UML objektumorientált modellezési nyelvvel készített diagramokat. A 080100.62 „Közgazdaságtan” és a 080500.62 „Üzleti informatika” irányú hallgatók oktatására szolgál.
Népszerű tudományos anyagok	Monográfia "Területi szervezetek faktor- és klaszterelemzése az ingatlangazdálkodás területén"	Javaslatokat adunk a kiválasztott régióban a HOA-t jellemző paraméterek faktoriális és klaszteranalízisére. Információt nyújt az azonos üzleti folyamatokkal rendelkező ingatlankezelő szervezetekről, és azonosítja a tevékenységüket befolyásoló főbb tényezőket.
Monográfia "Algoritmusok információcseréhez egy ingatlankezelő szervezetben"	Bemutatjuk az IS működésének általános algoritmusát, az előfizetők számára információs szolgáltatásokat megvalósító IS szoftvermodulok működési algoritmusait, valamint a szoftvermodulok interakciójának algoritmusait. Információs rendszer felhasználói felületei. Modulok programkódjának fejlesztésének jellemzői MS Visual 2010 fejlesztői környezet segítségével
Cikk "Az előfizetők és információs rendszerek osztályozása az MKD-t kezelő szervezetekben"	Meghatározzák az ingatlankezelő szervezeten belüli információcsere mintázatait, az információcsere során várható adatok összetételét és mennyiségét, az információcsere során várható adattranszformációkat, valamint a bemeneti és kimeneti adatok megjelenítési formáit.
Cikk "Többszeres szimulációs modell kidolgozása a lakástulajdonos-szövetségek tevékenységének modellezésére"	Megközelítéseket adunk a témakör ágenseinek kialakításához, valamint szimulációs modell kidolgozásához. Bemutatjuk a lakástulajdonos egyesületek tevékenységének különböző kiindulási adatokkal történő modellezésének eredményeit.
Cikk "A HOA-k üzleti szabályainak kialakítása"	Megközelítéseket adunk az üzletszabályzat kialakításához. Megfontolásra kerültek az IBM ILog segítségével üzleti szabálykezelő rendszer megvalósításának lehetőségei. Példa az üzleti szabályok használatára a döntéshozatalban.
Cikk "Algoritmusok kialakítása ingatlankezelő szervezet információs rendszeréhez"	Figyelembe veszi az információs rendszer algoritmusának felépítését, az információs szolgáltatásokat és a szervezet adatbázisával való információcserét megvalósító szoftvermodulok algoritmusainak felépítését.
	Cikk "Holisztikus megközelítés alkalmazása a HOA tevékenységek kulcsfontosságú teljesítménymutatóinak komplexumának kialakítására"	A cikk a holisztikus megközelítés rendelkezéseinek alkalmazását vizsgálja olyan mutatószámok kialakítására, amelyek lehetővé teszik az ingatlankezelő szervezet stratégiai és taktikai (operatív) céljainak megvalósulását értékelő rendszer létrehozását, a szervezet állapotának felmérését. valamint az információs rendszer előfizetőinek üzleti tevékenységének valós idejű nyomon követése.
Cikk "Információs szolgáltatások lakóházak kezeléséhez"	Figyelembe veszik a külföldi információs rendszerek által a társasházakban lévő ingatlanok tulajdonosai (bérlői) számára nyújtott információs szolgáltatásokat.
Cikk "Adatbázis kialakítása a HOA információs rendszeréhez"	Figyelembe veszik az adatmodelleket, az adattárolási és -feldolgozási technológiát, az adatösszetételt, a felhasználói felületeken és a kimeneti dokumentumokban való tükrözéshez szükséges adatformátumokat, az adattípusokat, a táblázatok javasolt összetételét, valamint a táblák közötti kapcsolatok diagramját.
Cikk "A HOA szervezeti elemzése és üzleti folyamatmodellje"	Megfontolandó egy modellkészlet kialakítása: stratégiai célmeghatározási modell, szervezeti-funkcionális modell, funkcionális-technológiai modell, mennyiségi modell folyamat-szerepmodellje, adatszerkezeti modell (milyen formában a HOA szabályozás ill. külső környezeti objektumok leírása), üzleti folyamatmodellek

Rizs. 6.2.

(Vállalati Információs Rendszer)

Vállalati információs rendszerek kiszervezése

A termelési funkciók és üzleti folyamatok vállalati információs rendszereken alapuló kiszervezése lehetővé teszi a modern menedzsment legújabb vívmányainak és „legjobb gyakorlatainak” a felhasználását. A vállalati információs rendszerek bevezetése az üzleti folyamatok újratervezésének középpontjában áll (Üzleti folyamat...
(Outsourcing és munkaerő-kihelyezés: csúcstechnológiás menedzsment)

Vállalati információs rendszerek integrációs mintái

Az információs rendszerek integrációs mintái a tervezési minták osztályozásának felső szintjét képviselik. Az alacsonyabb szintű besorolási mintákhoz hasonlóan az integrációs minták között is megkülönböztethető a strukturális minták egy csoportja. A szerkezeti minták egyetlen integrált ...
(Bevezetés a szoftverarchitektúrába)

A VÁLLALKOZÁS INFORMÁCIÓS RENDSZERÉNEK FUNKCIÓS FELADATAI ÉS A VÁLLALKOZÁS MODERN INFORMÁCIÓS RENDSZERÉNEK ALAPMODULAI. MODULOK INTEGRÁLÁSA

A modul fogalmának értelmes jelentése magában foglalja a funkcionális alrendszerek, funkcionális feladatok összehasonlítását funkcionális feladat alapú megközelítéssel a modern modernitás fő moduljaival. Rizs. 6.2. A funkcionális feladatok összehasonlítása egy vállalat modern ICISP információs rendszereinek fő moduljaival, ...
(Vállalati Információs Rendszer)

A VÁLLALKOZÁS INFORMÁCIÓS RENDSZERÉNEK FOGALMA, FEJLŐDÉS TÖRTÉNETE ÉS OSZTÁLYOZÁSA. A VÁLLALAT INTEGRÁLT VÁLLALATI INFORMÁCIÓS RENDSZEREI

Az információs rendszerek fogalma és osztályozása történeti fejlődésük folyamatában változik. A cél azonban változatlan marad, és a vállalatirányítási hatékonyság elérésével függ össze. A vállalatirányítás hatékonysága számos tényező kölcsönhatásától függ, köztük filozófiai, történeti, ...
(Vállalati Információs Rendszer)

A MODERN INFORMÁCIÓS TECHNOLÓGIÁK JELLEMZŐI A VÁLLALKOZÁS INFORMÁCIÓS RENDSZEREIBEN

MODERN TECHNOLÓGIÁK A VÁLLALATI INFORMÁCIÓS RENDSZEREKBEN AZ ADATBEVITEL SZERVEZÉSÉRE Az üzleti tranzakciókra vonatkozó információkat minden származási forrásból időben be kell vinni az operatív adatbázisba. Ez lehetővé teszi a további adatfeldolgozás hatékony megszervezését az információs ...
(Vállalati Információs Rendszer)

Bevezetés

A szóban forgó dolgozat a Donetsk OJSC Donetsk Manufaktúra alapján készült a Cleonelly üzlet számára.

A Donyeck Manufaktúra OJSC egyik vezető tevékenysége ruházati cikkek széles skáláját gyártja, elsősorban fürdőköpenyeket, lepedőket és törölközőket. Ezenkívül a cég festett pamutfonalat gyárt szövéshez és kötéshez.

Az automatizált információs technológiák fejlődése együtt jár az információfeldolgozás és -továbbítás új típusú technikai eszközeinek megjelenésével, a számítógépek használatának szervezeti formáinak fejlesztésével, az infrastruktúra új kommunikációs eszközökkel való telítésével. A piaci viszonyok fejlődése a vállalkozási tevékenység új típusainak megjelenéséhez, és mindenekelőtt az információs üzlettel foglalkozó cégek létrejöttéhez, az információs technológiák fejlődéséhez, azok fejlesztéséhez, az automatizált információs technológiák összetevőinek elterjedéséhez vezetett, különösen az információs és számítási folyamatokat automatizáló szoftvertermékek. Ide tartoznak még a számítástechnikai berendezések, a kommunikációs eszközök, az irodai berendezések és bizonyos típusú szolgáltatások – információs, műszaki és tanácsadói szolgáltatások, képzés stb. Ez hozzájárult az információs technológiák gyors elterjedéséhez és hatékony felhasználásához az irányítási és termelési folyamatokban, szinte egyetemes alkalmazásukhoz és sokrétűséghez.

A különféle célú eszközök tervezésével és fejlesztésével foglalkozó vállalkozások jelenleg széles körben alkalmazzák a számítógéppel segített tervezés – CAD (CAD) és a gyártási folyamatok felügyelete – ACS (SCADA / DCS) különféle eszközeit. A saját tervezésű készülékek esetében azonban ki kell fejleszteni saját eszközeinket a teljesítményük figyelésére és a termékminőség elemzésére.

A Cleanelly üzletben lévő raktárban lévő termékek elszámolásának technológiai folyamata magában foglalja az eladott termékek nyilvántartásának szakaszát.

Ennek a diplomatervnek a célja egy automatizált munkaállomás (AWP) megvalósítása, amely lehetővé teszi az áruház raktárában lévő termékek nyomon követését.

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

¾ elemzi az üzlet üzleti folyamatait;

¾ feltárni a fejlesztés alatt álló termék szállításának szakaszában felmerülő információáramlásokat;

¾ fogalmi és logikai adatmodellek kidolgozása;

¾ szoftverek fejlesztése termékek könyvelésére szolgáló automatizált munkaállomásokhoz

¾ az információs rendszer gazdasági hatékonyságának felmérése.

1 Szoftverkövetelmények fejlesztése

1.1 Meglévő megoldások elemzése

Jelenleg számos olyan vállalat létezik, amely egyesíti a közvetlen termékfejlesztést és ezeknek a termékeknek a vezérlőrendszereinek fejlesztését. Ilyen rendszereket olyan jól ismert cégek fejlesztenek, mint az 1: C Enterprise és a Zvezda. Az ilyen rendszerekben az anyagok ellenőrzése, elszámolása, a kapott információk feldolgozása történik.

Az „1C: Enterprise” alkalmazott megoldások rendszere, amely azonos elvekre és egyetlen technológiai platformra épül. A menedzser választhat olyan megoldást, amely megfelel a vállalkozás jelenlegi igényeinek, és a vállalkozás növekedésével vagy az automatizálási feladatok bővülésével tovább fejlődik.

Az 1C: Enterprise szoftverrendszert a dinamikusan fejlődő modern vállalkozások számviteli és menedzsment-automatizálási problémáinak széles körének megoldására tervezték. Sürgős számviteli és gazdálkodási problémák megoldása Az 1C: Enterprise rendszer programjainak összetétele a vállalkozások aktuális igényeire összpontosul. Az "1C" cég sorozatos szoftvermegoldásokat gyárt, amelyek a tipikus számviteli és menedzsment feladatok automatizálására szolgálnak a vállalatoknál. Az 1C kiadású megoldások megkülönböztető jellemzője a standard megoldásokban szereplő funkciók összetételének alapos tanulmányozása. Az „1C” cég elemzi az „1C: Enterprise” rendszer programjait használó felhasználók tapasztalatait, és figyelemmel kíséri igényeik változásait.

A Wholesale Base rendszerem fő előnyei közé tartozik a rendszer bevezetésének viszonylag alacsony költsége, valamint számos egyéb előny:

¾ A létrehozott alkalmazások megbízhatósága. A szoftvercsomagnak (PC) nemcsak a felhasználói hibákkal szemben, hanem a kommunikációs rendszer hibáival szemben is ellenállónak kell lennie.

¾ Az interfész egyszerű használata;

¾ Magas szintű rendszerbiztonság, amely nemcsak bizonyos rendszererőforrások elérhetőségének és információbiztonságának ellenőrzését jelenti a működés minden szakaszában, hanem a végrehajtott műveletek nagyfokú megbízhatósággal történő nyomon követését is.

1.2 Tartományelemzés

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

A CASE az üzleti folyamatok elemzésére és átszervezésére szolgál. – Minden Fusion Process Modeler (BPwin) legfelső szintű eszköz, amely támogatja az IDEF0 (Funkcionális modell), a DFD (Dataflow Diagram) és az IDEF3 (Workflow Diagram) módszertant. A BPwin egy hatékony szoftvertermék az összetett üzleti folyamatok változásainak elemzésére, dokumentálására és tervezésére szolgáló modellek létrehozására. A BPwin egy eszközt kínál a vállalat működésével kapcsolatos összes szükséges információ összegyűjtésére, és ezen információk koherens és konzisztens modell formájában történő ábrázolására.

A rendszer funkcionalitását tekintve. Az IDEF0 (Integration Definition for Function Modeling) módszertan keretein belül egy üzleti folyamatot egymással kölcsönhatásban álló munkaelemek összességeként ábrázolunk, és az egyes munkák által felhasznált információkat, emberi és termelési erőforrásokat jelenítjük meg. A funkcionális modell célja, hogy leírja a vállalat meglévő üzleti folyamatait (ún. AS-IS modell) és az ideális állapotot. – mire kell törekedni (TO-BE modell). Az IDEF0 módszertan hierarchikus diagramrendszer felépítését írja elő, azaz. rendszertöredékek egységes leírása. Először a rendszer egészének leírását és a külvilággal való interakcióját (kontextusdiagram) írják le, majd elvégzik a funkcionális bontást. – a rendszer alrendszerekre oszlik, és minden rendszer külön leírásra kerül (dekompozíciós diagramok). Ezután az egyes alrendszereket kisebbekre bontják, és így tovább, hogy elérjék a kívánt részletezési szintet.

Ha a modellezés során szükséges kiemelni a vállalati technológia sajátos szempontjait, a BPwin lehetővé teszi, hogy a modell bármely ágára váltson DFD vagy IDEF3 jelölésre. A Data Flow Diagramming (DFD) diagramok kiegészíthetik az IDEF3 modellben már tükröződőt, mivel leírják az adatfolyamokat, lehetővé téve nyomon követését, hogyan történik az információcsere a rendszeren belül az üzleti funkciók között. Ugyanakkor a DFD diagramok figyelmen kívül hagyják az üzleti funkciók közötti interakciókat.

Az elvégzett munka sorrendjét tekintve. És még pontosabb képet kaphatunk, ha a modellt IDEF3 diagramokkal egészítjük ki. Ez a módszer felhívja a figyelmet az események végrehajtásának sorrendjére. A logikai elemeket az IDEF3 tartalmazza, amely lehetővé teszi az üzleti folyamatok fejlesztésének alternatív forgatókönyveinek modellezését és elemzését.

Az üzlet raktárában futó üzleti folyamatok figyelembevételéhez mindössze két módszert kell használni: IDEF0 és DFD. A rendszer modellezésének folyamata az IDEF0-ban a kontextus meghatározásával kezdődik, azaz. a rendszer vagy általában az üzleti folyamatok leírásának legelvontabb szintje.

IDEF0 modell... A "Szállítói rendelés kialakítása", "Az áruk átvétele", "Az áruk kiadása" üzleti folyamatok tanulmányozásához vegye figyelembe az IDEF0 diagram formájában bemutatott diagramokat. Az IDEF0 rendszer kölcsönható tevékenységek vagy funkciók gyűjteményeként jelenik meg.

Az IDEF0 módszertana négy fő koncepción alapul.

Az első a koncepció funkcionális blokk (Tevékenységdoboz)... A funkcionális blokk grafikusan téglalap formájában van ábrázolva, és a vizsgált rendszer keretein belül megszemélyesít néhány konkrét funkciót.

A funkcionális blokk mind a négy oldalának megvan a maga sajátos jelentése (szerep), míg:

A felső oldal Control;

A bal oldal Bemenetre van állítva;

A jobb oldal Kimenetre van állítva;

Az alsó oldal Mechanizmusra van állítva.

Az IDEF0 módszertan második „bálnája” az interfészív (nyíl) fogalma. Az interfész ív grafikus megjelenítése egyirányú nyíl. Minden interfészívnek saját névvel kell rendelkeznie (Arrow Label). Interfészívek segítségével különféle objektumok jelennek meg, amelyek valamilyen szinten meghatározzák a rendszerben zajló folyamatokat. Ebben az esetben a nyilakat attól függően, hogy a munkatéglalap melyik oldalába lépnek be, vagy melyik oldalt hagyják el, a következőkre osztjuk:

Bemeneti nyilak (a funkcionális blokk bal oldalán találhatók) - a munkavégzés során megváltozott adatokat vagy objektumokat jelölik;

Vezérlőnyilak (a funkcionális blokk felső oldalán találhatók) - ábrázolják azokat a szabályokat és korlátozásokat, amelyek miatt a munkavégzés történik;

Kilépési nyilak (kilépés a funkcionális blokk jobb oldaláról) - a munka eredményeként megjelenő adatokat vagy objektumokat jelölik;

A mechanizmus nyilai (a funkcionális blokk alsó szélében találhatók) - erőforrásokat (például berendezéseket, emberi erőforrásokat) jelölnek.

Az IDEF0 szabvány harmadik alapkoncepciója a Dekompozíció. A dekompozíciós elvet akkor alkalmazzuk, amikor egy összetett folyamatot alkotó funkciókra bontunk.

A dekompozíció lehetővé teszi a rendszermodell fokozatos és strukturált ábrázolását az egyes diagramok hierarchikus struktúrája formájában, ami kevésbé túlterheltté és könnyen emészthetővé teszi.

Az IDEF0 végső koncepciója a Glossary. Minden IDEF0 elemhez: diagramok, funkcionális blokkok, interfész ívek, a meglévő szabvány magában foglalja az elem által megjelenített objektumot jellemző releváns definíciók, kulcsszavak, narratívák stb. halmazának létrehozását és karbantartását. Ezt a készletet szószedetnek nevezik, és ez az elem lényegének leírása.

Tekintsük a „Cleonelly” OJSC DMM áruház raktárában előforduló üzleti folyamatok diagramjait:

A rendszer általános láthatósága érdekében szükséges a „Vállalkozás raktárának tevékenysége” kontextus felépítése (lásd 1.1. ábra).

1.1. ábra - "A vállalkozás raktári tevékenységei" diagram

A kontextus megállapítása után lebontás történik, azaz. a következő diagramok felépítése a hierarchiában.

Minden további diagram a magasabb diagram egyik művének részletesebb leírása. A kontextuális munka dekompozíciójára egy példa látható az 1.2. ábrán. Így a teljes rendszer a kívánt részletességi szintig alrendszerekre van osztva, ez a rendszer három szintre oszlik.

1.2. ábra - Első szintű bontási diagramok

1.3 ábra – „Áruk vámkezelése” diagram

1.4. ábra – „Árukibocsátás” diagram

1.5. ábra - "Áruk feladása" diagram

DFD. Ez a módszertan az elemzett IS - előrevetített vagy ténylegesen létező - modelljének felépítésén alapul. A módszertannak megfelelően a rendszermodellt adatfolyam-diagramok (DFD) hierarchiájaként határozzuk meg, amely leírja az információnak a rendszerbe történő bemenetétől a felhasználónak történő kimenetéig történő átalakítása aszinkron folyamatát. A DFD diagramok általában a szervezet munkafolyamat-rendszerének jelenlegi munkájának megjelenítésére szolgálnak. A DFD diagramokat leggyakrabban az IDEF0-ban megvalósított üzleti folyamatmodell kiegészítésére használják.

Az adatfolyamdiagram fő összetevői a következők:

Külső entitások (grafikusan négyzetként ábrázolva) - olyan anyagi tárgyat vagy egyént jelölnek, amely információforrás vagy -fogadó. Például: ügyfelek, személyzet, beszállítók, ügyfelek, raktár;

Rendszerek / alrendszerek (grafikusan úgy néz ki, mint egy lekerekített sarkú téglalap) - olyan funkciókat vagy folyamatokat jelöl, amelyek feldolgozzák és megváltoztatják az információkat;

Az adattároló eszközök egy absztrakt információ tárolására szolgáló eszköz, amely bármikor tárolóeszközre tehető, és egy idő után visszakereshető, elhelyezésének és előhívásának bármilyen módja lehet. Általánosságban elmondható, hogy az adattár a leendő adatbázis prototípusa, és a benne tárolt adatok leírását az információs modellhez kell kapcsolni;

Adatfolyamok - meghatározza a forrástól a vevőhöz egy bizonyos kapcsolaton keresztül továbbított információt. Az adatfolyamot a diagramon egy nyíllal végződő vonal jelöli, amely az áramlás irányát jelzi.

Tekintsük a probléma adatfolyam diagramját (DFD) 1.6. ábra. Ez a diagram a dokumentumok mozgását mutatja, amikor "termékigénylés" érkezik egy szervezethez.

1.6. ábra – DFD „Árukibocsátás” diagram

Tekintsük a következő „Terméktávolság” adatfolyam diagramot (lásd 1.7. ábra). Bemutatja a munkavégzés folyamatát és az iratok mozgását az „árukiadás” során.

1.7. ábra – DFD diagram "Áruk vámkezelése"

Az adatfolyam-diagramokban az összes használt szimbólum egy nagy képet alkot, amely világos képet ad arról, hogy milyen adatokat használunk és milyen funkciókat lát el a munkafolyamat-rendszer. Ugyanakkor gyakran kiderül, hogy a meglévő, a cég tevékenysége szempontjából fontos információáramlások nem valósulnak meg megbízhatóan, át kell szervezni őket.

A frottírtermékeket értékesítő vállalkozás szervezeti felépítését a Cleonelly áruház OJSC „Donetsk Manufactura M” cégének példáján vizsgáljuk:

Az irányítási rendszerek fejlesztése és az anyagok elszámolása érdekében sikeresen megoldhatják a problémákat:

1. Ez a szállított és tárolt áruk ellenőrzése.

2. Tájékoztatás a szállítókról és fogyasztókról

3. Információkat és a termékkel kapcsolatos műveleteket is tartalmaz

4. Tartalmazza a kiadott árujelentés naplóját

5. Tartalmaz egy árujegyzéket

6. Raktári funkciók automatizálása (bevétel, fogyasztás, leírás, árufoglalás)

7. Vásárolt és eladott áruk és szolgáltatások számláinak nyilvántartása és tárolása, valamint előleg, halasztott fizetés és áruszállítás számlázása

8. Számlakészítés, kiállított áruk elszámolása

9. Raktári leltár lebonyolítása egybevetési lap készítésével, hiány és többlet aktus

10. Árukészletek létrehozása

Amint jeleztük, a vállalkozás fő tevékenységi köre pamuttermékek értékesítése. A tervezési folyamat számos szakaszból áll, amelyeket a tervező vállalkozások vezetési struktúrái gondosan kidolgoznak a vállalkozás teljes élettartama alatt. Ez a folyamat egyszerre nem változtatható meg, hiszen magában a vállalkozás számos részlegét, külső alvállalkozókat és a projektvállalkozás ügyfeleit érinti. Ezért a vállalkozások óvakodnak a tervezési és fejlesztési menedzsment folyamatokhoz kapcsolódó információs rendszerek bevezetésétől. Általában az orosz vállalkozások saját fejlesztéseiket használják ezen a területen.

1.3 Követelmények begyűjtése

A "Nagykereskedelmi Áruház Munkaállomása" információs rendszerének (IS) tervezésekor olyan követelményeket kellett összegyűjteni, amelyek elősegítik egy olyan felület kialakítását, hogy a végfelhasználó (az üzlet dolgozója) kényelmesen dolgozhasson a kifejlesztett IS-vel. .

A követelményfejlesztés az a folyamat, amely magában foglalja a rendszerkövetelmény-specifikációs dokumentum létrehozásához és jóváhagyásához szükséges tevékenységeket.

Az anyagok elszámolásának és ellenőrzésének automatizálási folyamatának megvalósításához szükséges, hogy az információs rendszer a következő funkcionális követelményeket teljesítse:

¾ az eredmények dokumentálása.

¾ Az információs rendszert Visual Fox Pro integrált környezeten alapuló programként kell megvalósítani.

A program Windows 2000 / NT / XP operációs rendszeren működik.

A követelmények kialakításának négy fő szakasza van (1.8. ábra):

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

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

Követelmények meghatározása és a vonatkozó dokumentáció elkészítése;

A követelmények tanúsítása.

A követelmények összegyűjtése a szoftvertervezés fontos szakasza, hiszen itt kell helyesen és helyesen megfogalmazni az összes vásárlói igényt.

1.4 Követelmények specifikációja

A megfelelő követelmények meghatározása valószínűleg a legkritikusabb lépés egy szoftverprojektben. Nagyon fontos, hogy a projekt formátuma megfeleljen a fejlesztőcsapat által összeállított szoftverre vonatkozó követelményeknek, ellenkező esetben ezek a követelmények nem támogathatók és nem jeleníthetők meg a szoftvertermékben. A Software Requirements Specification (SRS) a szoftverfejlesztés teljes életciklusának központi eleme. Ez nem csak egy származékos dokumentum, amely meghatározza egy szoftverprojekt specifikációit, hanem a minősítési és átvételi tesztelés lefolytatásához használt fő dokumentum is. A tanúsítás a projektmenedzserek munkájának minőségi értékelése. Meghatározza, hogy egy szoftvertermék milyen mértékben felel meg a megállapított követelményeknek. Az SRS-specifikáció a tanúsítás kritériumaként használt rendszerkövetelmények rögzítésének mechanizmusaként működik.

Az SRS alapján megállapodás jön létre az ügyfelek és a szoftvertermék gyártói között. Az SRS specifikáció teljes mértékben leírja azokat a funkciókat, amelyeket a fejlesztett szoftverterméknek teljesítenie kell. Ez lehetővé teszi a potenciális felhasználók számára, hogy meghatározzák, hogy a termék milyen mértékben felel meg igényeiknek, valamint a termék módosításának módjait úgy, hogy az a leghasznosabb legyen problémáik megoldásában.

Csökkenti a fejlesztési időt. Az SRS specifikáció elkészítésében az ügyfél szervezetén belül különböző csoportok vesznek részt. Alaposan megvizsgálnak minden követelményt, még a projekt tényleges fejlesztésének megkezdése előtt. Ez csökkenti a későbbi újratervezés, kódolás és tesztelés valószínűségét.

Az SRS specifikáció követelményeinek alapos tanulmányozása figyelmen kívül hagyásokat, félreértéseket és következetlenségeket tárhat fel a fejlesztési ciklus korai szakaszában, amikor a problémák sokkal könnyebben javíthatók, mint később.

Az SRS specifikáció a költségbecslés és ütemezés alapja lesz. A termékleírás valós alapja egy projekt költségbecslésének. Olyan környezetben, ahol létezik a formális ajánlat fogalma, az SRS-t az ajánlat vagy az ár becslésének érvényesítésére használják.

A jól megírt specifikációkkal az SRS-ek szervezeti szinten sokkal hatékonyabb tanúsítási és auditterveket dolgozhatnak ki. A fejlesztési szerződés részeként az SRS referenciapontot ad az előírásoknak való megfelelés értékeléséhez.

Az SRS specifikáció megkönnyíti a szoftvertermék új felhasználókhoz való átvitelét, valamint más számítógépekre való telepítését. Így a vevők könnyebben átadhatják a szoftverterméket a szervezet más részlegeinek, a fejlesztőknek pedig a többi vásárlónak.

Az SRS specifikáció a korszerűsítés alapjául szolgál. Ez a dokumentum magával a termékkel foglalkozik, nem a projektfejlesztési folyamattal, így az elkészült termék kiterjesztéseként is használható.

A követelmények meghatározásának és meghatározásának folyamata után szükséges a követelmények érvényesítése.

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

1.5 A követelmények tanúsítása

Az érvényesítésnek bizonyítania kell, hogy a követelmények valóban meghatározzák azt a rendszert, amelyet az ügyfél szeretne. A követelmények érvényesítése azért fontos, mert a követelményspecifikáció hibája a rendszer átdolgozásához és magas költségekhez vezethet, ha a rendszer fejlesztési folyamata során vagy a gyártásba helyezés után derül ki.

A követelmények tanúsítási folyamata során különféle típusú követelmények dokumentációs ellenőrzéseket kell végezni:

1. A követelmények helyességének ellenőrzése.

2. A konzisztencia ellenőrzése.

3. A teljesség ellenőrzése.

4. Megvalósíthatósági ellenőrzés.

Számos követelmény-igazolási módszer létezik, amelyek együtt vagy külön-külön is használhatók:

1. Követelmények áttekintése.

2. Prototípuskészítés.

3. Tesztszkriptek generálása.

4. A konzisztencia automatizált elemzése.

A prototípuskészítés a leginkább látható a rendszer ügyfél számára.

A prototípuskészítés megkezdése előtt létrehozhat egy felhasználói felület folyamatábráját. Ez a diagram a felhasználói felület fő elemei közötti kapcsolatok tanulmányozására szolgál.

A követelmények érvényesítésének következő lépése a közvetlen prototípuskészítés.

A szoftver prototípus egy javasolt új termék részleges vagy lehetséges megvalósítása. A prototípusok három fő feladat elvégzését teszik lehetővé: a követelmények megfogalmazási folyamatának tisztázása és kiegészítése, alternatív megoldások feltárása és a végtermék elkészítése.

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ának kiválasztása

Az IS fejlesztésének strukturális megközelítésének lényege az automatizált funkciókra való lebontásában (felosztásában) rejlik: a rendszer funkcionális alrendszerekre oszlik, amelyek viszont alfunkciókra, feladatokra oszlanak, stb. A particionálási folyamat meghatározott eljárásokig folytatódik. Az automatizált rendszer ugyanakkor fenntart egy holisztikus nézetet, amelyben az összes alkotóelem összekapcsolódik.

Valamennyi legelterjedtebb strukturális megközelítési módszer számos általános elven alapul. A következő alapelveket két alapelvként használjuk:

Oszd meg és uralkodj – az összetett problémák megoldásának elve sok kisebb, független, könnyen érthető és megoldható problémára bontással;

A hierarchikus rendezés elve a probléma alkotórészeinek hierarchikus fastruktúrákba való rendezésének elve, minden szinten új részletek hozzáadásával.

A strukturális elemzés elsősorban két eszközcsoportot használ a rendszer által ellátott funkciók és az adatok közötti kapcsolatok szemléltetésére. Az alapok minden csoportja bizonyos típusú modelleknek (diagramoknak) felel meg, amelyek közül a leggyakoribbak a következők:

SADT (Structured Analysis and Design Technique) modellek és kapcsolódó funkcionális diagramok;

DFD (Data Flow Diagrams) adatfolyam diagramok;

ERD (Entity-Relationship Diagrams) entitás-kapcsolat diagramok.

Az IS tervezési szakaszában a modellek kibővítése, finomítása és a szoftver felépítését tükröző diagramokkal egészül ki: szoftverarchitektúra, programblokk diagramok és képernyő diagramok.

A felsorolt ​​modellek együtt teljes leírást adnak az IP-ről, függetlenül attól, hogy az már meglévő vagy új fejlesztésű. A diagramok összetétele minden konkrét esetben a rendszer leírásának szükséges teljességétől függ.

2 AZ INFORMÁCIÓS RENDSZER TERVEZÉSE

2.1 Építészeti tervezés

Bármely összetett információs rendszer létrehozásakor kritikus szempont az architektúrája, ahol a jövőbeli funkcionális folyamatok és technológiák struktúrájának koncepcionális vízióját képviseli rendszerszinten és összekapcsolódásban. A szervezetek összetett információs rendszereit jellemzően magas szintű kölcsönhatásban álló komponensek összetételeként tervezik, amelyek maguk is lehetnek rendszerek. A szervezet információs rendszer-architektúrája megkönnyíti a rendszer megértését azáltal, hogy funkcionalitását és struktúráját úgy határozza meg, hogy a tervezési döntéseket feltárja, és lehetővé tegye a megfigyelő számára, hogy kérdéseket tegyen fel a tervezési követelmények teljesítésével, a funkcionalitás kiosztásával és az összetevők megvalósításával kapcsolatban.

A szervezet információs rendszerének architektúrája annak a modellje, hogy az információs technológia hogyan támogatja egy automatizált objektum fő céljait és fejlesztési stratégiáját. Lehetővé teszi a kritikus gondolkodást és egy elképzelés megfogalmazását arról, hogyan kell az információs rendszerek integrált készleteit felépíteni e célok elérése érdekében. Az információs rendszer-architektúra azt írja le, hogy az információs rendszerek, alkalmazások és emberek hogyan működnek egységesen, egységesen a szervezeten belül.

Így az információs rendszer architektúrája olyan, általánosan elfogadott komponensekből áll, amelyek az információs rendszer "építőköveit" adják. Ezeket az "építőkockákat" és jellemzőit a tervezési döntések igényeinek megfelelő részletességgel határozzák meg.

A szervezetek modern információs rendszereinek kialakításakor azok architektúráját sok érdekelt fél figyelembevételével kell kialakítani, a felhasználók számára érthetőnek kell lennie, lehetővé kell tennie a fejlesztők számára a rendszer tervezését és ütemezését, lehetővé kell tennie a kulcsfontosságú interfészek, funkciók és technológiák meghatározását, valamint a becslést. a projekt ütemezése és költségvetése. Ez megköveteli a modern információs rendszerek építészeinek felelősségét abban, hogy a rendszer fejlesztésének legkorábbi szakaszában kielégítő és működőképes koncepciót alkossanak, ennek a koncepciónak a sértetlenségét a fejlesztés során megőrizzék, és hogy az így létrejövő rendszer alkalmas-e a felhasználásra. az ügyfél. Az információs rendszer-architektúra ezzel szemben az információs rendszer-architektúrák kellő részletességű leírásának folyamata ahhoz, hogy hasznosabbá tegyük őket az információs rendszerek tervezésében.

A külföldi tapasztalatok tanulmányozása azt mutatja, hogy a fejlett országokban az információs rendszer architektúra kialakításánál a következő feltételeknek kell teljesülniük:

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

¾ a követelményekre való összpontosítás;

¾ összpontosítás a fejlesztésre;

¾ alkalmazkodási képesség;

¾ a rugalmasság igénye.

Mindezen feltételek betartása lehetővé teszi a szervezet információs rendszerének architektúrájának tökéletesebbé és hatékonyabbá tételét.

A jelenleg megvalósított fő szoftverarchitektúrák a következők:

¾ fájlszerver;

¾ kliens-szerver;

¾ többszintű.

Fájlszerver... Ez a hálózati hozzáféréssel rendelkező központosított adatbázisok architektúrája magában foglalja a hálózat egyik számítógépének kijelölését dedikált szerverként, amely a központi adatbázis fájljait tárolja. A felhasználói kéréseknek megfelelően a fájlszerverről a fájlok a felhasználók munkaállomásaira kerülnek, ahol az adatfeldolgozás nagy része megtörténik. A központi szerver többnyire csak a fájltárolás szerepét tölti be, nem vesz részt magának az adatok feldolgozásában. A munka befejezése után a felhasználók a feldolgozott adatokat tartalmazó fájlokat visszamásolják a szerverre, ahonnan más felhasználók elvihetik és feldolgozhatják azokat. Az adatkarbantartásnak ez a megszervezése számos hátránnyal jár, például ha több felhasználó egyszerre fér hozzá ugyanazokhoz az adatokhoz, a munkateljesítmény meredeken csökken, mivel meg kell várni, amíg az adatokkal dolgozó felhasználó befejezi a munkáját. Ellenkező esetben egyes felhasználók módosításait felülírhatják más felhasználók módosításai.

Kliens-szerver... Ez a koncepció azon az elgondoláson alapul, hogy az adatbázis fájlok tárolása mellett a központi szervernek kell elvégeznie a legtöbb adatfeldolgozást. A felhasználók egy speciális strukturált lekérdezési nyelven (SQL, Structured Query Language) érik el a központi szervert, amely a szerver által végrehajtott feladatok listáját írja le. A felhasználói kéréseket a szerver fogadja és adatfeldolgozási folyamatokat generál benne. Válaszul a felhasználó egy már feldolgozott adatkészletet kap. Nem a teljes adathalmaz kerül átvitelre a kliens és a szerver között, ahogy az a fájlszerver technológiában történik, hanem csak azok az adatok, amelyekre a kliensnek szüksége van. Egy csak néhány soros felhasználói lekérdezés sok táblát és több millió sort tartalmazó adatfeldolgozást generálhat. Válaszul az ügyfél csak néhány számot kaphat. A kliens-szerver technológia lehetővé teszi, hogy elkerülje a hatalmas mennyiségű információ hálózaton keresztüli továbbítását azáltal, hogy az összes adatfeldolgozást egy központi szerverre helyezi át. Ezen túlmenően a megfontolt megközelítés elkerüli a fájlszerver technológiára jellemző ütközéseket, amikor több felhasználó ugyanazokat az adatokat módosítja. A kliens-szerver technológia több kliens konzisztens adatmódosítását valósítja meg, biztosítva az adatok automatikus integritását. Ezek és néhány más előny nagyon népszerűvé tette a kliens-szerver technológiát. Ennek a technológiának a hátrányai közé tartozik a központi szerver magas teljesítményigénye. Minél több kliens éri el a szervert, és minél nagyobb a feldolgozott adatmennyiség, annál erősebbnek kell lennie a központi szervernek.

Ezen megfontolások alapján az AWS architektúra tervezésekor a kliens-szerver technológiát vették alapul. Az elrendezési diagramok a rendszer szoftver- és hardverkomponensei közötti fizikai kapcsolatokat mutatják be.)

2.2 Az információs rendszer interfészének kialakítása

A felhasználói felületen gyakran csak a program megjelenését értjük. A valóságban azonban a felhasználó az egész rendszert egészként érzékeli rajta keresztül, ami azt jelenti, hogy az ilyen megértése túl szűk. A valóságban a felhasználói felület magában foglalja a tervezés minden olyan aspektusát, amely befolyásolja a felhasználó és a rendszer közötti interakciót. Nem csak a képernyőt látja a felhasználó. A felhasználói felület számos összetevőből áll, mint például:

felhasználói feladatok halmaza, amelyeket a rendszer segítségével old meg;

rendszervezérlők;

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

programképernyők látványtervezése.

Íme néhány a jó felhasználói felület legjelentősebb üzleti előnyei:

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

a rendszer fenntartási költségeinek csökkentése;

az alkalmazottak termelékenységvesztésének csökkentése a rendszer bevezetése során és a kieső termelékenység gyorsabb helyreállítása;

a személyzet moráljá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 rendszerfunkciók elérhetősége a maximális számú felhasználó számára.

Az AWP nagykereskedelmi bázist kliens-szerver technológiát alkalmazó alkalmazásként fejlesztik.

2.2.1 A vezérlőprogram felhasználói felülete

Az "AWP nagykereskedelmi bázis" fő modulja a Luck.exe modul, amely az 1.4. szakasz 1.9. ábráján bemutatott használati eset diagram fő funkcióinak megvalósítását biztosítja.

Egy információs rendszer fejlesztése során az egyik fő feladat a legegyszerűbb és nem terhelt felület létrehozása. Ez a szoftvertermék interfésze, amely segíti a felhasználókat az információs rendszerrel "kommunikálni", párbeszédként működik a felhasználó és a rendszer között.

Program felület, adminisztrációs rész:

1. a program kezdő formája. Ez az űrlap a szoftvertermék elindításakor indul el, ezzel megkezdődik a felhasználói párbeszéd a rendszerrel (2.3. ábra);

2. admin űrlap. Ebben a formában valósul meg az információs rendszer teljes körű kezelése, azaz. adatok felvétele, törlése, módosítása az adatbázisban, valamint szükség esetén jelentések megtekintése, kinyomtatása (2.4. ábra);

3. "Ügyfelek" űrlap, ennek köszönhetően teljes körű információkat láthat a vállalkozás ügyfeleiről (2.7. ábra);

4. "Beszállítók" űrlap, ennek köszönhetően teljes körű információkat láthat a vállalkozás ügyfeleiről (2.8. ábra).

A program felhasználói felülete:

Az áru érkezési ablakában az áruk nyilvántartása folyamatban van. Az űrlap ezen lapjának kiválasztásakor a felhasználónak először kell

A költségmenüben a raktári alkalmazott által az áruk kiadására és értékesítésére végzett műveletek találhatók.

A menüegyenlegekben az áruk számbavétele, a raktárban tárolt cikkek megnevezése.

A pénztáros menüben itt tárolódnak a jóváírási és pénzkiáramlási megbízások információi. (Képernyőképek)

2.2.2 A vezérlőelemek felhasználói felületei

2.0 ábra A program főmenüje

A program főablakát az ábra mutatja. 1.9. Amint az ábrán látható, a fent már ismertetett főmenü mellett egy vezérlőpult is lesz benne ("Bevétel", "Fogyasztás", "Hozzáférés", "Egyenlegek", "Pénztár", "Átértékelés gombok" ", "Analytics", " Directories "," Service "és" Kilépés a programból ").

2.1 Ábra Átvétel vagy átvétel menüablak a raktárban.

2.2. ábra Fogyasztás menüablak

2.2. ábra A programhoz való hozzáférési jogokat szabályozó menüablak.

2.3 ábra A többi áru menüablakja.

2.4 ábra Pénztárgép menüablak.

2.4. ábra Átértékelés menüablak.

2.3 Adatbázis tervezés

Az adatbázis megtervezéséhez a Computer Associates Int cég ERwin 4.0-ját használták.

Az ERwin egy hatékony és könnyen használható adatbázis-tervező eszköz, amely széles körű elfogadásra és népszerűségre tett szert. Ez biztosítja a legmagasabb termelékenységet az adatbázis-vezérelt alkalmazások fejlesztése és karbantartása során. A teljes folyamat során - az adatbázist meghatározó információs követelmények és üzleti szabályok logikai modellezésétől a fizikai modell meghatározott jellemzőknek megfelelő optimalizálásáig - az ERwin lehetővé teszi az adatbázis szerkezetének és alapvető elemeinek vizuális megjelenítését.

Az ERwin nem csak a legjobb adatbázis-tervező eszköz, hanem egy gyors létrehozási eszköz is. Az ERwin a céladatbázis fizikai jellemzőinek megfelelően optimalizálja a modellt. Más eszközökkel ellentétben az ERwin automatikusan fenntartja a logikai és fizikai séma konzisztenciáját, és a logikai konstrukciókat, például a sok-sok kapcsolatokat fizikai megvalósításokká fordítja le. Megkönnyíti az adatbázis tervezését. Ehhez elegendő egy grafikus E-R modellt (object-relationship) létrehozni, amely minden adatigényt kielégít, és az üzleti szabályokat megadni egy olyan logikai modell létrehozásához, amely minden elemet, attribútumot, kapcsolatot és csoportosítást megjelenít. Erwinnek két szintje van a modell bemutatásában – logikai és fizikai. A logikai réteg az adatok absztrakt nézete, amelyen az adatok úgy jelennek meg, ahogyan a valós világban kinéznek, és a valós világban is nevezhető, például „hűséges ügyfél”, „részleg” vagy „ Munkavállaló vezetékneve". A logikai szinten ábrázolt modellobjektumokat entitásoknak és attribútumoknak nevezzük. Az adatmodell logikai szintje univerzális, és semmi köze a DBMS egy konkrét megvalósításához. Az adatmodell logikai szintjének három alszintje van, amelyek különböznek az adatokkal kapcsolatos információk megjelenítésének mélységében:

Entity Relationships Diagram (ERD);

Kulcsalapú modell (KB);

Teljesen hozzárendelt modell (FA).

Entitásdiagram – A kapcsolat olyan entitásokat és kapcsolatokat tartalmaz, amelyek tükrözik a tartomány alapvető üzleti szabályait. Egy ilyen diagram nem túl részletes, tartalmazza a főbb entitásokat és a köztük lévő kapcsolatokat, amelyek kielégítik az alapvető követelményeket. Entitásdiagram – A kapcsolatok sok-sok kapcsolatokat tartalmazhatnak, és nem tartalmazhatnak kulcsleírásokat. Az ERD-t jellemzően prezentációkra és az adatszerkezetről a téma szakértőivel folytatott megbeszélésére használják. A kulcsalapú adatmodell az adatok részletesebb nézete. Tartalmazza az összes entitás és elsődleges kulcs leírását, és a tárgyterületnek megfelelő adatszerkezetet és kulcsokat hivatott reprezentálni.

A logikai modell az adatstruktúra legrészletesebb reprezentációja: az adatokat harmadik normál formában ábrázolja, és magában foglalja az összes entitást, attribútumot és kapcsolatot (lásd a B függeléket).

Fizikai adatmodelléppen ellenkezőleg, az adott DBMS-től függ, valójában a rendszerkatalógus megjelenítése. A modell fizikai rétege információkat tartalmaz az adatbázisban lévő összes objektumról. Mivel az adatbázis-objektumokra nincsenek szabványok (például nincs szabvány az adattípusokra), a modell fizikai rétege a DBMS konkrét megvalósításától függ. Következésképpen a különböző modellek több különböző fizikai szintje felelhet meg egy modell azonos logikai szintjének. Ha a modell logikai szintjén nem nagyon számít, hogy az attribútum milyen konkrét adattípussal rendelkezik (bár az absztrakt adattípusok támogatottak), akkor a modell fizikai szintjén fontos minden információt leírni a konkrét fizikai objektumokról - táblázatok, oszlopok, indexek, eljárások stb... Az adatmodell logikai és fizikai szintre bontása lehetővé teszi számos fontos probléma megoldását.

A fizikai adatmodellt a B. függelék mutatja be.

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

A Visual FoxPro egy vizuális relációs adatbázis-kezelő rendszer, amely jelenleg elérhető a Microsofttól. A legújabb verzió a 9.0. A FoxPro programozási nyelvet használja. A 7.0-s rendszerverzió Windows 9x operációs rendszereken és NT kerneleken, 8.0 és 9.0 verziókon futhat – csak Windows XP, 2000, 2003 alatt.

A FoxPro az xBase programozási nyelv egyik dialektusa. Főleg relációs DBMS-ek fejlesztésére használják, bár más programosztályok fejlesztésére is használható.Amint fentebb említettük, a VFP nyelv egy erősen kiegészített és kiterjesztett xBase nyelv. A Visual FoxPro-ban egy programozási nyelv, vagyis a nyelv alapkonstrukciója az osztály fogalma. Az xBase eredeti verziója egy tisztán strukturált nyelv, az eljárások és funkciók alapkoncepciójával. Így a Visual FoxPro modern programozási nyelv lehetővé teszi a "régimódi" programozás kombinálását az eljárások tömegének leírásával, és az OOP stílusban, összetett osztályhierarchiát hozva létre.

Azért választottam ezt a programozási nyelvet, mert a következő előnyökkel rendelkezik:

¾ Egy jól ismert adatbázis-tábla formátum, amely megkönnyíti az információcsere megszervezését más Microsoft Windows alkalmazásokkal.

A relációs adatbázisok modern szervezése, amely lehetővé teszi az adatbázistáblákról, azok tulajdonságairól, indexeiről és kapcsolatairól információ tárolását, hivatkozási integritási feltételek beállítását, helyi és távoli nézetek létrehozását, szerverkapcsolatokat, tárolt eljárásokat, amelyek több mint 50 különböző típusú esemény bekövetkezésekor futnak le. (VFP 7.0-9.0).

Nagy sebességű munkavégzés nagy adatbázisokkal.

Jól látható az adatbázisokkal való munkavégzés: a többfunkciós Data session ablakban megtekintheti a nyitott adatbázis táblák listáját, azok kapcsolatait, szűrőit, indexsorrendjét, pufferelési módokat, átválthat struktúramódosítási módokra, táblainformációkkal dolgozhat stb.

Nagy sebességű alkalmazásfejlesztés a Wizards, Designers, Builders, IntelliSense tippek mód használatával programszöveg írásakor, a programok hibakeresésére és tesztelésére szolgáló rendszer.

Kliens-szerver alkalmazások fejlesztésének képessége Oracle és Microsoft SQL Server adatbázis-kiszolgálókon tárolt adatokkal, valamint más Microsoft Windows alkalmazásokkal ODBC és OLE használatával

A VFP rendszert professzionális programozók számára szánják, így nincs értelme a menüt és a nyelvet oroszosítani - minden programozó számára az algoritmikus nyelv angol szintaxisa ismerősebb, mint az orosz.

2.5 Modulok tervezése

Foglalkozzunk részletesebben az egyik programmodul tervezésével, és annak példáján tekintsük át a projekt létrehozásához szükséges lépéseket.

Példaként a „Felvételi kérelmet ad ki” használati esetet megvalósító modul tervezését veszem figyelembe.

Először is írjuk le az ebben a használati esetben előforduló eseményfolyamokat.

A használati eset előfeltétele az ügyféltől érkező kérelem beérkezése.

5. A használati eset akkor kezdődik, amikor az ügyfél benyújtja a kérelmét.

6. A vezető megnyitja a Nyugta űrlapot.

7. A vezető határozza meg a jelentkezés időpontját.

8. A menedzser megadja a termék nevét.

9. A menedzser beírja az átvett áru mennyiségét.

10. A vezető beírja a pályázat összegét.

11. A vezető bezárja az űrlapot.

12. A használati eset véget ér.

A felhasználási eset utófeltétele egy kérelem regisztrációja a rendszerben és egy új ügyfél megjelenése a főlap naplójában.

Tekintsünk egy sorozatdiagramot erre a használati esetre. Amint az ezen az ábrán látható, a menedzser az Érkezési űrlapot megnyitva több művelet végrehajtását idézi elő - automatikusan (vezetői szempontból) a jelentkezés dátuma kerül kitöltésre. Jelentkezéskor az ügyfelek listája az alapból töltődik ki az elsődleges információkkal. Ezt követően a menedzser megadja az összes szükséges adatot, és rákattint az "Elfogadás" gombra. Ebben az esetben a következő műveleteket hajtják végre. Minden adat átkerül a tárolt eljáráshoz.

3 Az információs rendszer megvalósítása és érvényesítése

3.1 Alkalmazás megvalósítás

Az alkalmazás megvalósítása lényegében az egyik munkaigényes szakasz az információs rendszer fejlesztője számára, mert a megrendelő által támasztott követelményeket egyértelműen és helyesen kell integrálni a rendszerbe. Egyelőre nem léteznek olyan szoftvertermékek, amelyek az úgynevezett vevő igényeihez tudnának "igazkodni", és a rendszer megvalósításához olyan funkciókat biztosítanának, amelyek ezeknek a követelményeknek megfelelnének. Ezért minden fejlesztőnek meg kell választania az optimális környezetet a rendszer fejlesztéséhez, de meg kell jegyezni, hogy egy alkalmazás implementációja során nem lehet programkódot írni. A programkód írása során valósulnak meg bizonyos funkciók, amelyeket a rendszernek végre kell hajtania. A rendszer megvalósításához kiválasztott környezettől függően a programkód másképp fog kinézni, egy olyan környezetben, mint a Microsoft Visual FoxPro, egy programkód lesz, a Visual Basicben egy másik stb.

Ebben az esetben az alkalmazást a Microsoft Visual FoxPro programban valósították meg.

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

1. A rendszer kezdő formája. Ez az űrlap egy gombos forma, és ennek megfelelően minden gomb a saját funkcióját látja el. Az adminisztrátori regisztráció gomb a 3.1 ábrán látható Ez a gomb az adminisztrátori panelt megnyitó funkciót hajtja végre, ha a felhasználó rendelkezik ilyen jogosultsággal a rendszerhez.

2. Menü gomb érkezés. Ezzel a gombbal nyomon követheti az áruház raktárába érkező árukat 3.2 ábra.

3. A menü gombjában a raktárból kiadott áruk kiadásának nyilvántartása történik 3.3 ábra.

4. A hozzáférési menü gombjában a program használati jogait szabályozzuk 3.4 ábra.

5. A menü "maradékok" gombjában az üzlet raktárában tárolt anyagokról információkat tárolunk 3.5. ábra.

6. A pénztár menü gomb a bejövő és kimenő készpénzes utalványokról tárol információkat 3.6. ábra.

7. A menügomb átértékelése során az áruk új árához tartozó árváltozásokat hajtják végre. 3.7. ábra.

3.1 ábra - A rendszer kiindulási formája

3.2 ábra - A raktárba történő árubeérkezések elszámolásának formája.

3.3. ábra – Kiadott áruk elszámolási formája.

3.4 ábra – A programhoz való hozzáférési jogokat szabályozó űrlap.

3.5 ábra – A raktárban lévő többi áru formája.

3.5. ábra – Nyomtatvány pénztárbizonylatokról és pénztárbizonylatokról.

3.6. ábra – Az árukkal kapcsolatos műveletek formája.

Az alkalmazás tesztelése

A tesztelés egy program végrehajtásának folyamata a hibák észlelése érdekében. A tesztelés a következőket nyújtja:

Hibafelismerés;

A program funkcióinak céljának való megfelelésének bemutatása;

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

A megbízhatóság megjelenítése a program minőségének mutatójaként.

A 3.2. ábra a tesztelési folyamat információáramlását mutatja be.

A tesztelési folyamat bejáratánál három adatfolyam található:

Program szövege;

Kezdő adatok a program indításához;

Várható eredmények.

Teszteket végeznek, és minden kapott eredményt értékelnek. Ez azt jelenti, hogy a tényleges teszteredményeket összehasonlítják a várt eredményekkel. Ha eltérést talál, a rendszer hibát rögzít, és megkezdődik a hibakeresés.

A teszteredmények összegyűjtése és kiértékelése után megkezdődik a szoftver minőségének és megbízhatóságának megjelenítése. Ha rendszeresen előfordulnak súlyos, tervezési változtatásokat igénylő hibák, akkor a szoftver minősége, megbízhatósága gyanús, és a tesztelés megerősítése szükséges.

A tesztelés során felhalmozott eredmények formálisabb módon értékelhetők. Ehhez szoftvermegbízhatósági modelleket használnak, amelyek a megbízhatóságot a hibaarány valós adatai alapján jósolják meg.

A szoftvertesztelésnek két alapelve van:

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

Szerkezeti tesztelés (fehér dobozos tesztelés).

A "white box" módszer tesztelésekor a program belső felépítése ismert. A tesztelés tárgya itt nem a program külső, hanem belső viselkedése. Ellenőrzik a program összes elemének felépítésének helyességét és egymás közötti kölcsönhatásuk helyességét.

A fekete doboz tesztelése (funkcionális tesztelés) lehetővé teszi a bemeneti adatok kombinációinak beszerzését, amelyek teljes körűen ellenőrizhetik a program összes funkcionális követelményét //. A szoftverterméket itt "fekete doboznak" tekintjük, amelynek viselkedése csak a bemenetei és a megfelelő kimenetei alapján határozható meg.

A fekete doboz elv nem alternatívája a fehér doboz elvének. Inkább egy kiegészítő megközelítésről van szó, amely a hibák más osztályát észleli.

A fekete doboz tesztelése a következő hibakategóriákra keres:

Hibás vagy hiányzó funkciók;

Interfész hibák;

Hibák a külső adatstruktúrákban vagy a külső adatbázis elérésében;

Jellemző hibák (szükséges memóriakapacitás stb.);

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

Ellentétben a fehér dobozos teszteléssel, amelyet a tesztelési folyamat korai szakaszában hajtanak végre, a fekete doboz tesztelést a tesztelés későbbi szakaszaiban használják. A fekete doboz tesztelésekor figyelmen kívül hagyjuk a program vezérlőstruktúráját. Itt a figyelem a szoftverrendszer definíciójának információs területére összpontosul. Ebben a fázisban a tesztelés a megoldás élő gyártási környezethez való alkalmasságára összpontosít. A fő hangsúly a hibák kijavításán és súlyosságuk meghatározásán, valamint a termék kiadásra való felkészítésén van.

A tesztelési szakaszban két fő feladatot oldanak meg:

Megoldás tesztelése - A tervezési szakaszban elkészített és a fejlesztési szakaszban kibővített és tesztelt teszttervek végrehajtásra kerülnek;

Pilot üzemeltetés - a megoldás tesztkörnyezetben történő üzembe helyezése és tesztelése jövőbeli felhasználók bevonásával és valós rendszerhasználati forgatókönyvek megvalósítása. Ezt a feladatot a telepítési szakasz kezdete előtt hajtják végre.

A tesztelési szakasz célja a megoldás kereskedelmi üzembe helyezésekor felmerülő kockázat csökkentése.

Ahhoz, hogy a tesztelési szakasz sikeres legyen, meg kell változtatni a projekthez való hozzáállását, és a fejlesztőnek át kell térnie az új funkciók fejlesztéséről a megoldás megfelelő minőségének biztosítására.

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

Az alapteszt alacsony szintű műszaki tesztelés. Ezt maga a fejlesztő hajtja végre a programkód írása során. A "fehér doboz" módszert alkalmazzák, nagy a hibaveszély.

Használhatósági tesztelés - magas szintű tesztelés, amelyet a tesztelő és a termék jövőbeni felhasználói végeznek. A „fekete doboz” módszert alkalmazzák.

Alfa- és béta-tesztelés – Az alfa-kód alapvetően az MSF-folyamatmodell fejlesztési szakaszában létrehozott összes forráskód, a bétakód pedig az a kód, amelyet a tesztelési szakaszban teszteltek. Ezért az alfa kódot az MSF folyamatmodell fejlesztési szakaszában, a béta kódot pedig a tesztelési szakaszban tesztelik.

Kompatibilitási tesztelés – A fejlesztés alatt álló megoldásnak képesnek kell lennie a meglévő rendszerekkel és szoftvermegoldásokkal való integrálására és együttműködésére. A tesztelés ezen formája a kifejlesztett megoldás integrálhatóságának és meglévő rendszerekkel való interakciós képességének tesztelésére összpontosít. Ebben az esetben ellenőrizni kell az alkalmazás megfelelő működését a felhasználó berendezésén és a felhasználó által használt szoftvert.

Teljesítményteszt – annak ellenőrzésére összpontosít, hogy az alkalmazás megfelel-e a teljesítmény követelményeinek és a kényelem szintjének sebesség tekintetében.

Dokumentációs és súgórendszer tesztelése – Minden kifejlesztett támogató dokumentumot és súgórendszert tesztelnek.

A kísérleti üzemeltetés egy megoldást tesztel ipari környezetben. A kísérleti üzem fő célja annak bemutatása, hogy a megoldás ipari körülmények között is stabilan működik, és megfelel az üzleti követelményeknek. A kísérleti üzem során a megoldást valós körülmények között tesztelik. A kísérleti működés lehetővé teszi a felhasználók számára, hogy visszajelzést adjanak a termék teljesítményéről. E véleménytől vezérelve a fejlesztő minden lehetséges problémát kiküszöböl, vagy előre nem látható körülmények esetén cselekvési tervet készít. Végső soron a kísérleti művelet lehetővé teszi a döntés meghozatalát, hogy kezdeményezzük-e a teljes telepítést, vagy elhalasztjuk a telepítést megzavaró problémák megoldásáig.

A kialakított információs rendszer kísérleti működési folyamatának tervét a 3.2. táblázat tartalmazza.

3.2. táblázat – Kísérleti üzemeltetési terv

Akció		Leírás
1. A siker kritériumainak megválasztása		A fejlesztő és a tesztelők meghatározzák a sikerkritériumokat, és megállapodnak azokban.
2. A felhasználók kiválasztása és a telepítés helye		A kísérleti tesztelés felhasználói és fejlesztői oldaláról résztvevő csapata alakul. Meghatározzák a kísérleti folyamat telepítésének helyét.
3. Felhasználók és telepítési helyek felkészítése		A felhasználók – a próba résztvevőinek – képzése folyamatban van. A telepítési hely előkészítése folyamatban van.
4. Fejlesztői verzió telepítése		A kísérleti verzió telepítve van, és szerepel a munkában.
5. A prototípus verzió támogatása és felügyelete		A felhasználók és a rendszer munkájának nyomon követése, működésben segítségnyújtás, információgyűjtés a rendszer működéséről
6. A felhasználók visszajelzései és az eredmények értékelése		A felhasználók kifejtik véleményüket a rendszer működéséről, rámutatnak a hiányosságokra, hibákra.
7. Változások, kiegészítések bevezetése	A hibákat kijavítják, tervezési vagy folyamatmódosításokat hajtanak végre. A javított eredményeket a felhasználók dolgozhatják és értékelhetik.
8. Telepítési döntések	Ha a kísérleti tesztelési munka eredménye kielégíti a felhasználókat, döntés születik a rendszer telepítéséről.

3.2 Alkalmazástelepítési módszertan

Ebben a szakaszban a fejlesztő (vagy csapat) telepíti a megoldáshoz szükséges technológiákat és komponenseket, a projekt a karbantartási és támogatási szakaszba lép, végül az ügyfél jóváhagyja azt. A telepítés után a csapat értékeli a projektet, és megkérdezi a felhasználókat, hogy megállapítsa elégedettségüket.

A telepítési szakasz céljai:

¾  a megoldást ipari környezetbe átvinni;

¾  a megrendelő általi elismerés a projekt befejezéséről.

A helyspecifikus összetevők telepítése több szakaszból áll: előkészítés, telepítés, betanítás és hivatalos jóváhagyás.

A rendszertelepítési szakasz eredménye a karbantartási és támogatási rendszerek, egy dokumentumtár, ahol a projekt során kifejlesztett dokumentumok és kódok összes verziója található.

A fejlesztés alatt álló rendszer kiépítéséhez intézkedési terv készült, amelyet a 3.1. táblázat mutat be.

3.1. táblázat – Alkalmazástelepítési terv

Akció	A művelet leírása
1. Biztonsági mentés	A felhasználói adatokról az ő részvételével és jóváhagyásával biztonsági másolatot készítünk az információk cserélhető adathordozóra (CD, DVD) történő átvitelével.
2. A megoldás alapelemeinek beépítése	A megoldás működését biztosító technológiák alkalmazása. Ebben az esetben a Visual FoxPro összetevő telepítése
3. A kliens alkalmazás telepítése	Átvitel a felhasználó számítógépére és a kifejlesztett IS és adatbázis végleges verziójának telepítése
4. Képzés	A felhasználók képzettek a rendszerrel való munkavégzésre, a fejlesztő meg van győződve arról, hogy az ügyfelek helyesek és megértik az IP munkáját
5. A projekt tudásbázisának átadása a megrendelőnek	Minden projektdokumentációt átadunk a megrendelőnek
6. A projekt lezárása	Projektzáró jelentés készül. Az ügyfél aláírja az átvételi igazolást.

Az AWP normál működéséhez Microsoft WindowsXP operációs rendszer szükséges.

4 Információs projektmenedzsment

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

Az IS tervezési módszertan egyik alapfogalma a szoftvere (életciklus-szoftver) életciklusának fogalma. A szoftver életciklusa egy folyamatos folyamat, amely attól a pillanattól kezdődik, amikor döntés születik a létrehozásának szükségességéről, és a szolgáltatásból való teljes kivonás pillanatában ér véget.

A szoftver életciklusát szabályozó fő szabályozó dokumentum az ISO / IEC 12207 (ISO – Nemzetközi Szabványügyi Szervezet – Nemzetközi Szabványügyi Szervezet, IEC – Nemzetközi Elektrotechnikai Bizottság – Nemzetközi Elektrotechnikai Bizottság) nemzetközi szabvány. Meghatározza az életciklus szerkezetét, amely tartalmazza azokat a folyamatokat, műveleteket és feladatokat, amelyeket a szoftver létrehozása során végre kell hajtani.

Az ISO / IEC 12207 nem kínál konkrét életciklus-modellt és szoftverfejlesztési módszereket. Az életciklus-modell egy olyan struktúraként fogható fel, amely meghatározza a végrehajtás sorrendjét és az életciklus során végrehajtott folyamatok, cselekvések és feladatok kapcsolatát. Az életciklus-modell az IS sajátosságaitól és a létrehozásának és működésének feltételeitől függ.

Ma a szoftver életciklusának számos modellje létezik, de a legnépszerűbb és legelterjedtebb két modell:

Spirálmodell (lásd 4.1. ábra);

Iteratív modell.

4.1 ábra – A szoftver életciklusának spirális modellje

Információs rendszer létrehozásához, pl. A "Raktári alkalmazottak nagykereskedelmi raktárának automatizált munkahelye" iteratívát választottuk. Az iteratív modell sajátossága, hogy formális módszer, független fázisokból áll, szekvenciálisan hajtják végre, és gyakran áttekintik (4.2. ábra). Az iteratív megközelítés jól bevált az IS-ek építésében, amelyekhez a fejlesztés legelején minden követelmény pontosan és kellően teljeskörűen megfogalmazható, hogy a fejlesztők számára szabadságot biztosítson ezek műszaki szempontból a lehető legjobb megvalósításában. kilátás.

Az iteratív modell előnyei:

a modellt jól ismerik a nem szoftverfogyasztók és a végfelhasználók.

Kényelem és könnyű használat, mert minden munka szakaszosan történik (a modell fázisai szerint);

A követelmények stabilitása;

A modell érthető;

Még a gyengén képzett személyzetet is (tapasztalatlan felhasználó) tudja irányítani a modell felépítése;

A modell rendezetten kezeli a bonyolultságot, és jól működik olyan projekteknél, amelyek ésszerűen érthetőek;

A modell elősegíti a projektmenedzsment szigorú ellenőrzésének megvalósítását;

Megkönnyíti a projektmenedzser munkáját a fejlesztőcsapat tervezésében és összeállításában.

4.2. ábra – A szoftver életciklusának iteratív modellje

A modell fázisai:

Az elemzési szakaszban meghatározzák, hogy a rendszernek milyen funkciókat kell ellátnia, kiemelik a legfontosabb, elsősorban kidolgozást igénylő funkciókat, ismertetik az információs igényeket;

A tervezési szakaszban a rendszer folyamatait részletesebben megvizsgáljuk. A funkcionális modellt elemzik, és szükség esetén korrigálják. A rendszer prototípusai készülnek;

A rendszer fejlesztése a megvalósítás szakaszában zajlik;

A megvalósítás szakaszában a kész terméket bevezetik a szervezet meglévő rendszerébe. A felhasználói képzés folyamatban van;

A karbantartási szakaszban a szoftvertermék szervizelésre kerül (bármilyen kiegészítés vagy változtatás a termék funkcionálisabb működése érdekében).

A szoftverfejlesztési életciklus-modell kiválasztása fontos lépés. Ezért egy projekt esetében a szoftverfejlesztési életciklus-modell kiválasztása az alábbi folyamatok alkalmazása során történhet.

A projekt megkülönböztető kategóriáinak elemzése a táblázatokban.

Válaszoljon az egyes kategóriákhoz tartozó kérdésekre, kiemelve az "igen" és a "nem" szavakat.

Fontosság szerint rangsorolja az egyes kategóriákhoz kapcsolódó kategóriákat vagy kérdéseket azon projekt vonatkozásában, amelyhez elfogadható modellt választanak.

Fejlesztői csapat... A lehetőségek alapján a fejlesztőcsapat személyi állományának kiválasztása még a szoftverfejlesztési életciklus modelljének megválasztása előtt megtörténik. Egy ilyen csapat jellemzői (lásd G. függelék, G.1. táblázat) fontos szerepet játszanak az életciklus-modell kiválasztásának folyamatában, ami azt jelenti, hogy a csapat jelentős segítséget tud nyújtani a szoftvertermék életciklus-modelljének kiválasztásában, hiszen az felelős a kidolgozott életciklus-modell sikeres megvalósításáért. ...

Felhasználói csapat... A projekt kezdeti szakaszában teljes képet kaphat arról a felhasználói csapatról (lásd Függelék ÉS I.1. Táblázat), akik a kifejlesztett szoftverrel fognak dolgozni, és annak a jövőbeni kapcsolatáról a fejlesztő csapattal a projekt során. Egy ilyen nézet segít a megfelelő modell kiválasztásában, mivel egyes modellek fokozott felhasználói részvételt igényelnek a projekt fejlesztésében és tanulmányozásában, mivel a követelményeket a felhasználó a fejlesztési folyamat során némileg megváltoztathatja, ezért a fejlesztőnek ismernie kell ezeket a változásokat, ill. hogyan kell ábrázolni ezeket a változásokat a szoftverben.

4.2 A szoftverprojekt céljának és terjedelmének meghatározása

Az áruk raktári könyvelésére kifejlesztett szoftvertermék automatizálja a raktárban lévő árukra vonatkozó adatok fogadásának, strukturálásának és tárolásának folyamatát, valamint leegyszerűsíti a jelentések kiállításának folyamatát.

A szoftverprojekt céljai a következők: - az áruk elszámolására szolgáló rendszer létrehozása és telepítése. Ezt a rendszert belső használatra szánják a Cleonelly munkatársai, főként a cég raktárának alkalmazottai.

A szoftvertermék hatókörének meghatározásához az alábbiakban leírjuk, hogy mi legyen és mi nem lehet szoftverprojekt.

A szoftverprojektnek a következőnek kell lennie:

Szervezeten belüli használatra;

Projekt a többfelhasználós hozzáférés megvalósítására;

Olyan projekt, amely képes a vállalat termékével kapcsolatos információk bevitelére, módosítására és tárolására;

Olyan projekt, amely képes a rendszer felhasználóira vonatkozó információk bevitelére, módosítására és tárolására;

Olyan projekt, amely képes a szervezet vevőire és beszállítóira vonatkozó információk bevitelére, megváltoztatására és tárolására, akik a megkötendő ügyletek tárgyát képezik;

Egy projekt, amely elvégzi a külső jelentéstétel kialakítását.

4.3 Struktúra létrehozása a művek lépésenkénti listájához

Egyedi termék vagy szolgáltatás (projekteredmény) létrehozásához egy bizonyos munkasorozatot kell végrehajtania. A projekttervezés feladata ezen munkák időzítésének és költségének pontos becslése. Minél pontosabb az értékelés, annál jobb a projektterv minősége. A pontos értékeléshez jól ismernie kell a projekt hatókörét, vagyis tudnia kell, milyen munkát kell elvégezni az eredmény eléréséhez. Csak a tervezési munkák listájának összeállítása után becsülik meg mindegyikük időtartamát, és osztják ki a végrehajtásukhoz szükséges erőforrásokat. És csak ezután tudja megbecsülni az egyes feladatok költségét és ütemezését, valamint a kiegészítés eredményeként a projekt teljes költségét és időtartamát. Éppen ezért a projekttervezés első lépése a munkakör meghatározása. A tervezési munka körének meghatározása a projekt szakaszainak (vagy fázisainak) meghatározásával kezdődik. Például a "Raktáron lévő áruk elszámolása" rendszer létrehozására irányuló projektben a következő fázisok emelhetők ki:

Szoftverkövetelmények fejlesztése;

Információs rendszerek tervezése;

Az információs rendszer bevezetése és tanúsítása;

Rendszer implementáció.

A fázisok összetételének és eredményeinek meghatározása után meg kell határozni ezeknek a fázisoknak egymáshoz viszonyított sorrendjét és a megvalósítás határidejét. Ezután meg kell határozni, hogy a fázisok milyen munkákból állnak, milyen sorrendben valósulnak meg ezek a munkák, és milyen határidőket kell betartani, amikor elkészülnek.

A lépésenkénti munkalista (4.3. ábra) egy szoftvertermék, például az MS Project 2003 segítségével készült.

4.3 ábra - A munkák lépésenkénti listája

4.4 A szoftverfejlesztés időtartamának és költségének becslése

Időtartam becslése. A munkák lépésenkénti listájának elkészítése után kerül meghatározásra (4.3. ábra, 4.3. bekezdés). Ez a becsült időtartam a Gantt-diagram (K. melléklet) segítségével látható.

A diagramok a projektfájlban található információk grafikus megjelenítési eszközei. A diagramokból vizuális képet kaphat a feladatok sorrendjéről, relatív időtartamáról és a projekt egészének időtartamáról.

A Gantt-diagram a projektterv grafikus ábrázolásának egyik legnépszerűbb módja, és számos projektmenedzsment programban használják.

Az MS Projectben a Gantt-diagram a projektterv fő vizualizációs eszköze. Ez a diagram egy grafikon vízszintes idővonallal és függőleges feladatok listájával. Ebben az esetben a feladatokat jelölő szegmensek hossza arányos a feladatok időtartamával.

A Gantt-diagramon a sávok mellett további információk jeleníthetők meg (a feladatok mellett a bennük szereplő erőforrások neve és a feladat befejezésekor történő betöltése jelenik meg).

Költségbecslés

A projekt a következőkből áll feladatokat , vagyis egy bizonyos eredmény elérését célzó tevékenységek. A feladat teljesítése érdekében erőforrások .

Az erőforrások fontos tulajdonsága a projektben való felhasználásuk költsége (Cost). Az MS Projectben kétféle erőforrásköltség létezik: időalapú díj és használati költség.

Az időalapú ráta (Rate) az erőforrás időegységenkénti felhasználásának költségében van kifejezve, például 100 rubel óránként vagy 1000 rubel naponta. Ebben az esetben az erőforrás projektben való részvételének költsége az az idő, ameddig az erőforrás a projektben dolgozik, megszorozva az óradíjjal.

Ebben az esetben az időarányt alkalmaztuk (4.4. ábra) Az erőforrások felhasználásának összköltsége a 4.5. ábrán látható.

4.4. ábra – Időarány az erőforrás-felhasználásban

Ezen az ábrán látható, hogy a rendszerfejlesztő óránként 50 rubelt kap egy projekt végrehajtása során; üzleti elemző 45 rubelt kap óránként, tesztelő 38 rubelt óránként. A túlóra díját nem tartalmazza.

4.5. ábra - A projekt erőforrásainak felhasználásának összköltsége

4.5 Projekterőforrások elosztása

A „Készletszámviteli” rendszer erőforrás-elosztásának egy töredéke a 4.6. ábrán látható

4.6. ábra - A projekt erőforrásainak elosztásának töredéke

A projektben végzett minden egyes munkához hozzá van rendelve egy erőforrás, amely elvégzi ezt a munkát. Az ábrán látható az egyes erőforrásokra fordított munkaerő teljes mennyisége és az egy adott napon eltöltött órák száma.

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 számítják ki a projekt gazdasági hatékonyságát. Ez a számítás megmutatja, mennyire jövedelmező egy projekt vagy egy teljesen veszteséges projekt. A projekt gazdasági hatékonyságának kiszámításakor ki kell számítani a projekt megtérülési idejét. A megtérülési időszak azt az időszakot mutatja, amely alatt a projekt megtérül.

Beviteli adat.

További nyereség a projekt végrehajtásából (DP) = 38 000 rubel. További profitot jósoltak a cég szakemberei.

Kezdeti beruházás (IC) = 39396,47 rubel. A kezdeti beruházások megfelelnek a projekt erőforrásainak felhasználásának teljes költségének (4.5. ábra, 4.6. pont)

Diszkontráta (i) = 12%.

Az az időszak, amelyre a projektet tervezték (n) = 2 év.

További nyereség a projekt végrehajtásából (DP) = 38 000 rubel.

A projekt megvalósításának éves költségei (Z 1) = 15 000 rubel.

A projekt éves költségei (Z 2) = 10 000 rubel.

Éves pénztárbizonylat (R 1) = 23 000 rubel.

Éves pénztárbizonylat (R 2) = 28 000 rubel.

A beruházási projektek értékelésekor a nettó jelenérték számítási módszerét alkalmazzák, amely lehetővé teszi a pénzáramlások diszkontálását: minden bevétel és költség egy időpontra kerül.

A vizsgált módszer központi mutatója az NPV (nettó jelenérték) – a pénzáramlások jelenértéke. Ez a befektetési tevékenység általánosított végeredménye abszolút értékben.

Fontos szempont a diszkontkamatláb megválasztása, amelynek tükröznie kell a pénzügyi piacon várható átlagos hitelkamatlábat.

A nettó jelenértéket (NPV) a 4.2 képlet alapján számítjuk ki

(4.2)

R k - évi pénztári bevételek n évre.

k - az évek száma, ameddig a projektet tervezik.

IC - induló beruházás.

i - diszkontráta.

Ennek a képletnek a számításai szerint NPV = 3460,67 RUB

Az NPV abszolút növekmény, mert megbecsüli, hogy a jelenérték mennyivel fedi át a jelenlegi költséget. Mivel az NPV> 0, a projektet el kell fogadni.

A befektetés megtérülését (ROI) a 4.3 képlet alapján számítjuk ki

(4.3)

Számított (ROI) = 108,78%

4.1 táblázat  Segédtábla a projekt megtérülési idejének számításához

= 1,84

Megtérülési idő n ok = 1,84 év (1 év 11 hónap)

Mivel a ROI => 100% (nevezetesen = 108,78%), a projekt nyereségesnek tekinthető.

(4.4)

Így a jövedelmezőségi index (PI) = 1,2

Az IS bármilyen célú működését biztosító elemeket a definíció tartalmazza. Ezek egy része - eszközök, módszerek és személyzet - az IS működését biztosítja, míg mások - információk tárolása, feldolgozása és kiadása - funkcionális jellemzőket jeleznek, pl. meghatározza, hogy az IS működése mely információs folyamatokból áll. Ezért az IS struktúráját kétféleképpen tekintjük: a funkcionális struktúrának és az IS struktúrájának, mint támogató alrendszerek halmazának.

A definíció szerint az IS funkcionális elemei a következő folyamatcsoportok (blokkok):

információk bevitele külső vagy belső forrásokból;

a bemeneti információk feldolgozása és kényelmes formában történő bemutatása;

információ kiadása a fogyasztók számára történő bemutatásra vagy átvitelre egy másik információs információs rendszerre;

A visszajelzés olyan információ, amelyet egy adott szervezet emberei dolgoznak fel a bemeneti információ javítása érdekében.

Funkcionális szerkezet Az információs rendszert egy blokkdiagram formájában mutatjuk be (1. ábra), amelyben a rendszer minden eleme blokk (az ábrán - téglalap) formájában jelenik meg, valamint a hivatkozások és azok irányai vannak feltüntetve. nyilak által.

Az egyes részeket (rendszerblokkokat) alrendszereknek nevezzük.

A funkcionális alrendszerek halmaza és összefüggései minden konkrét esetben a tárgyterülettől és a vállalkozás tevékenységének sajátosságaitól függenek, amelynek tevékenységét az információs rendszer biztosítja.

Az IS felépítése a támogató alrendszerek komplexeként is ábrázolható (2. ábra).

1. ábra. Az IC általános funkcionális blokkdiagramja.

Az információfeldolgozás jellegében és típusaiban eltérő AIS-ek esetében azonban a funkcionális diagram a feldolgozási alrendszerek halmazában különbözik. Például az AIPS (könyvtár, múzeum, jogi hivatkozás stb.) a felhasználó kérésére az információk bevitelét, rendszerezését, tárolását, keresését és kézbesítését végzi bonyolult adatátalakítások nélkül. Információdöntő rendszerek: ASOD, ACS, DSS - meghatározott algoritmus szerint dolgozzák fel az adatbázis információkat, azonban az információfeldolgozó alrendszerek összetételében is különböznek. Egy tervezési automatizálásra specializálódott CAD rendszer felépítésében speciális alrendszereket tartalmaz: műszaki dokumentáció, feladatképzés, szimuláció, számítási, és egyesek szakértői rendszerrel is rendelkezhetnek (lásd a 2. ábra blokkvázlatát).

2. ábra. CAD blokkdiagram

Tekintsünk egy másik típusú IS struktúrát: mint támogató alrendszerek komplexumát (3. ábra).

Az információs rendszer szerkezete alrendszerek halmazának tekinthető, függetlenül a terjedelemtől. Az alrendszer a rendszer része, valamilyen attribútum alapján kiválasztva. Ebben az esetben az osztályozás strukturális jellemzőjéről beszélnek, és az alrendszereket biztosítónak nevezik.

Így bármely információs rendszer felépítése reprezentálható támogató alrendszerek halmazával.

3. ábra. IS felépítése a támogató alrendszerek típusa szerint.

A támogató alrendszerek között általában megkülönböztetik az információs, műszaki, matematikai, szoftveres, szervezeti és jogi támogatást.

Információs támogatás- információs adatsorok halmaza, az információk egységes osztályozási és kódolási rendszere, egységes dokumentációs rendszerek, a szervezetben keringő információáramlás sémái, valamint az adatbázisok felépítésének módszertana. Az információs támogatási alrendszer célja a vezetői döntések meghozatalához szükséges megbízható információk időben történő kialakítása és eljuttatása.

Egységes dokumentációs rendszerekállami, köztársasági, ágazati és regionális szinten jönnek létre. A fő cél a társadalmi termelés különböző területei mutatóinak összehasonlíthatóságának biztosítása. Szabványokat dolgoztak ki, ahol a követelményeket megállapították:

egységes dokumentációs rendszerekre;

a különböző szintű irányítási dokumentumok egységes formáihoz;

a részletek és mutatók összetételére és szerkezetére;

az egységes okmányformák megvalósításának, karbantartásának és nyilvántartásának rendjéhez.

Az egységes dokumentációs rendszer megléte ellenére a legtöbb szervezet felmérése a tipikus hiányosságok egész sorát tárja fel:

rendkívül nagy mennyiségű dokumentum kézi feldolgozáshoz;

ugyanazok a mutatók gyakran ismétlődnek a különböző dokumentumokban;

a nagyszámú dokumentummal való munka elvonja a szakemberek figyelmét az azonnali problémák megoldásától;

vannak olyan mutatók, amiket létrehoznak, de nem használnak stb.

Ezen hiányosságok felszámolása az információs támogatás kialakításának egyik feladata.

Információs folyamatábrák tükrözi az információ mozgásának útvonalait, mennyiségét, az elsődleges információ származási helyeit és a keletkező információk felhasználását. Az ilyen rendszerek szerkezetének elemzésével lehetőség nyílik a teljes irányítási rendszer fejlesztésére irányuló intézkedések kidolgozására.

Az információs folyamatábrák felépítése és részletes elemzése, amely lehetővé teszi az információ útvonalainak és mennyiségeinek azonosítását, a mutatók megkettőzését és feldolgozási folyamatait, a következőket kínálja:

az ismétlődő és fel nem használt információk kiküszöbölése;

az információk osztályozása és racionális bemutatása.

Adatbázisépítés módszertana tervezésük elméleti alapjai alapján.

A módszertan alapfogalmai:

a szervezet teljes irányítási rendszerének céljainak, célkitűzéseinek, funkcióinak világos megértése;

az információ mozgásának azonosítása a keletkezés pillanatától a különböző irányítási szinteken történő felhasználásig, információáramlási sémák formájában elemzésre bemutatva;

a dokumentumkezelő rendszer fejlesztése;

osztályozási és kódolási rendszer elérhetősége és használata;

az információk összekapcsolódását tükröző fogalmi információ-logikai modellek létrehozásának módszertanának ismerete;

információs tömbök létrehozása számítógépes adathordozón, amelyhez modern technikai támogatás szükséges.

Ez a koncepció gyakorlatilag két lépcsőben valósul meg.

1. szakasz - a vállalat összes funkcionális részlegének vizsgálata annak érdekében, hogy:

ismeri tevékenységének sajátosságait és szerkezetét;

felépíteni egy diagramot az információáramlásról;

elemzi a meglévő dokumentumkezelő rendszert;

meghatározza az információs objektumokat és az attribútumok megfelelő összetételét (paraméterek, jellemzők), amelyek leírják azok tulajdonságait és célját.

2. szakasz - fogalmi információ-logikai adatmodell felépítése az 1. szakasz felmérésének eredményei alapján. Ebben a modellben az objektumok és azok attribútumai közötti összes kapcsolatot létre kell hozni és optimalizálni kell. Az információs-logikai modell az alapja, amelyre az adatbázis létrejön.

Technikai támogatás- az információs rendszer működtetésére szolgáló technikai eszközök készlete, valamint ezen eszközök és technológiai folyamatok megfelelő dokumentációja

A technikai eszközök komplexuma a következőkből áll:

bármilyen típusú számítógép;

információk összegyűjtésére, tárolására, feldolgozására, továbbítására és kiadására szolgáló eszközök;

adatátviteli eszközök és kommunikációs vonalak;

Irodai berendezések és eszközök automatikus információkereséshez;

működési anyagok stb.

A dokumentáció formalizálja a műszaki eszközök előzetes kiválasztását, működésük megszervezését, az adatfeldolgozás technológiai folyamatát, a technológiai berendezéseket. A dokumentáció nagyjából három csoportra osztható:

rendszerszintű, beleértve a műszaki támogatás állami és iparági szabványait;

specializált, amely egy sor módszert tartalmaz a technikai támogatás fejlesztésének minden szakaszához;

normatív hivatkozás, amelyet a műszaki támogatás számításai során használnak.

A technikai támogatás megszervezésének (a technikai eszközök igénybevételének formái) jelenleg két fő formája létezik: centralizált és részben vagy teljesen decentralizált.

A központosított technikai támogatás az információs rendszerben található nagy számítógépek és számítási központok használatán alapul. Ez a szervezeti forma megkönnyíti a szabványosítás irányítását és végrehajtását, de csökkenti a munkatársak felelősségét és kezdeményezőkészségét.

A technikai eszközök decentralizálása magában foglalja a funkcionális alrendszerek személyi számítógépeken történő megvalósítását közvetlenül a munkahelyeken. Ebben az esetben nagyobb személyes felelősséget követelnek meg a munkatársak, a vezetés nehezebben tudja megvalósítani a szabványosítást.

Jelenleg a részben decentralizált megközelítés elterjedtebb - a technikai támogatás megszervezése elosztott hálózatokon alapuló személyi számítógépekből és egy nagyszámítógépből álló, bármely funkcionális alrendszerre jellemző adatbázisok tárolására.

Matematikai és szoftveres- matematikai módszerek, modellek, algoritmusok és programok összessége az információs rendszer céljainak és célkitűzéseinek megvalósításához, valamint a technikai eszközök komplexumának normál működéséhez.

Az alapokhoz szoftver viszonyul:

menedzsment folyamatok modellezésére szolgáló eszközök;

tipikus vezetői feladatok;

a matematikai programozás módszerei, matematikai statisztika, sorelmélet stb.

Rész szoftver rendszerszintű és speciális szoftvertermékeket, valamint műszaki dokumentációt tartalmaz.

NAK NEK rendszerszintű szoftver magában foglalja a felhasználóknak szánt programok komplexeit, amelyek az információfeldolgozás tipikus problémáinak megoldására szolgálnak. A számítógépek funkcionalitásának bővítését, az adatfeldolgozási folyamatok vezérlését és menedzselését szolgálják.

Speciális szoftver egy adott információs rendszer létrehozásakor kifejlesztett programok összessége. Tartalmaz olyan alkalmazott szoftvercsomagokat (APP), amelyek megvalósítják a kifejlesztett, különböző fokú megfelelőségi modelleket, tükrözve egy valós objektum működését.

A szoftverfejlesztés műszaki dokumentációjának tartalmaznia kell a feladatok leírását, az algoritmizálási feladatot, a probléma gazdasági és matematikai modelljét, tesztpéldákat.

Szervezeti támogatás Olyan módszerek és eszközök összessége, amelyek szabályozzák a munkavállalók interakcióját a technikai eszközökkel és egymás között az IS kidolgozásának és működtetésének folyamatában.

A szervezeti támogatás a következő funkciókat valósítja meg:

a szervezet meglévő irányítási rendszerének elemzése, ahol az IS-t használni fogják, és az automatizálandó feladatok meghatározása;

feladatok elkészítése számítógépen történő megoldásra, ideértve az IS tervezési feladatmeghatározását és hatékonyságának megvalósíthatósági tanulmányát;

a szervezet összetételére és felépítésére vonatkozó vezetői döntések kialakítása, az irányítási rendszer hatékonyságának növelését célzó problémák megoldásának módszertana.

A szervezési támogatás a projekt előtti felmérés eredményei alapján jön létre az adatbázis felépítésének 1. szakaszában.

Jogi támogatás- az információs rendszerek létrehozását, jogállását és működését meghatározó, az információszerzés, átalakítás és felhasználás eljárását szabályozó jogi normarendszer.

A jogi támogatás fő célja a jogállamiság erősítése. A jogi keretek közé tartoznak a törvények, rendeletek, állami hatósági határozatok, minisztériumok, osztályok, szervezetek, önkormányzatok rendeletei, utasításai és egyéb normatív dokumentumai. A jogi támogatásban megkülönböztethető egy általános rész, amely bármely információs rendszer működését szabályozza, és egy helyi rész, amely egy adott rendszer működését szabályozza.

Az információs rendszer fejlesztési szakaszainak jogi alátámasztása magában foglalja a fejlesztő és a megrendelő közötti szerződéses jogviszonyra és a szerződéstől való eltérések jogi szabályozására vonatkozó előírásokat.

Az információs rendszer működési szakaszainak jogi támogatása magában foglalja:

információs rendszer állapota;

a személyzet jogai, kötelességei és felelősségei;

az információ létrehozásának és felhasználásának eljárása stb.

Ez az alrendszer-készlet szinte minden AIS-típusra általános. A támogató alrendszerek felépítése és összetettsége azonban az AIS típusától, az alkalmazási területtől és egyéb tényezőktől függ. Tehát a matematikai támogatás alrendszere az eredeti szoftverfejlesztés AIS-ében történik - a szabványos szoftverrel rendelkező AIS-ben ez hiányzik. A jogi támogatás alrendszere hiányozhat az AIS-ben cégen belüli célokra - ebben az esetben lehetőség van a szervezeti támogatás alrendszerére szorítkozni, amelyben többek között a jogi támogatás kérdései is megoldódnak; Az AIS független célokra, például információs szolgáltatási rendszerekre, rendelkezhet jogi támogatási alrendszerrel. A tényszerű adatbázissal rendelkező AIS-nek csak egy információs támogatási alrendszere van, amelyben bizonyos nyelvi kérdések megoldására lehet szükség. A dokumentumfilmes AIPS fejlett nyelvi támogatási alrendszerrel rendelkezik, mivel ezek a rendszerek komplex problémákat oldanak meg a felhasználói kérések szemantikai relevanciájának biztosításában a kiadott dokumentumok tartalmához képest. És ez általában nem csak a morfológiai elemzés szoftvermoduljai, hanem szótárak és karbantartásukra vonatkozó szabályok is.

Az IP létrehozásának és megvalósításának céljai.

Mi várható az információs rendszerek megvalósításától?

Az információs rendszerek bevezetése hozzájárulhat:

1. a dolgozók felmentése a rutinmunka alól és annak automatizálás miatti felgyorsítása;

2. a papír adathordozók cseréje mágneslemezekre vagy szalagokra, ami a papíron lévő dokumentumok mennyiségének csökkenéséhez vezet, ezáltal lehetőség nyílik az információfeldolgozás racionálisabb megszervezésére a számítógépen;

3. az információáramlás szerkezetének és a dokumentumkezelési rendszernek a vállalaton belüli javítása a konzisztencia hatására: egyszeri adatbevitel - többszörös és többcélú felhasználás ";

4. racionálisabb lehetőségek megszerzése a menedzsment problémák megoldására (matematikai módszerek és intelligens rendszerek bevezetésével stb.):

új piaci rések felkutatása;

termékek és/vagy szolgáltatások előállítási költségeinek optimalizálása;

a vevőkkel és beszállítókkal fenntartott kapcsolatok optimalizálása.

Az információs rendszerek fejlődésének szakaszai

Az IP fejlődésének története szakaszokra oszlik (2. táblázat), megközelítőleg a célok elfogadott számozásának megfelelően - az IP használatának megközelítése változik.

2. táblázat Az IP fejlesztés szakaszai.

Időszak	Információhasználati koncepció	Információs rendszerek típusai	Használat célja
1950-1960	Az elszámolási dokumentumok papír áramlása	Elszámolási bizonylatok feldolgozására szolgáló információs rendszerek elektromechanikus könyvelőgépeken	A dokumentumfeldolgozás sebességének növelése Egyszerűsített számlafeldolgozás és bérszámfejtés
1960-1970	Nélkülözhetetlen segítség a jelentések elkészítéséhez	Menedzsment információs rendszerek termelési információkhoz	A jelentéstételi folyamat felgyorsítása
1970-1980	A megvalósítás (értékesítés) vezetői ellenőrzése	Döntéstámogató rendszerek Rendszerek felső vezetés számára	A legracionálisabb megoldás mintavétele
1980-2000	Az információ stratégiai erőforrás, amely versenyelőnyt biztosít	Stratégiai információs rendszerek Automatizált irodák	A cég túlélése és jóléte

Az első információs rendszerek a múlt század közepén jelentek meg. Az 1950-es években számlák feldolgozására és bérszámításra tervezték, és elektromechanikus könyvelőgépeken valósították meg. Ez némileg csökkentette a papíralapú dokumentumok elkészítésének költségeit és idejét.

60-as évek az információs rendszerekhez való hozzáállás megváltozása jellemzi. A tőlük kapott információkat sokféleképpen kezdték felhasználni időszakos jelentésekhez. Ezen a napon a szervezeteknek olyan általános célú számítástechnikai eszközökre volt szükségük, amelyek sokféle funkciót képesek ellátni, nem csak a számlák feldolgozását és a fizetések kiszámítását, ahogyan ez korábban volt.

A 70-es években - a 80-as évek elején. az információs rendszereket kezdik széles körben alkalmazni a döntéshozatali folyamatot támogató és felgyorsító vezetői kontroll eszközeként.

A 80-as évek végére. az információs rendszerek használatának koncepciója ismét változik. Stratégiai információforrássá válnak, és bármely profilú szervezet minden szintjén használatosak. Ennek az időszaknak az információs rendszerei, a szükséges információkat időben biztosítva segítik a szervezetet abban, hogy tevékenységében sikereket érjen el, új termékeket és szolgáltatásokat hozzon létre, új értékesítési piacokat találjon, méltó partnereket biztosítson magának, megszervezi a termékek alacsony áron történő megjelenését, és még sok más.

Az információs rendszer modern értelmezése magában foglalja a személyi számítógép használatát, mint az információfeldolgozás fő technikai eszközét. Nagy szervezetekben a személyi számítógép mellett az információs rendszer műszaki bázisa lehet egy mainframe vagy egy szuperszámítógép. Ráadásul az információs rendszer technikai megvalósítása önmagában semmit sem fog jelenteni, ha nem vesszük figyelembe annak a személynek a szerepét, akinek az információt szánják, és aki nélkül lehetetlen az információ átvétele és bemutatása.

Bevezetés

1. Elemző rész

1.1 A társaság szervezeti felépítése

2 Az ügyfélszolgálati részleg és a munkaosztály szoftverének és hardverének elemzése

Projekt rész

2.1 A tárgykör leírása

2 Tervezési és megvalósítási módszerek megvalósíthatósági tanulmánya

3 Adatbázis tervezés

4 Fogalmi adatmodell a Chen szabványban

5 ER diagram ERwin környezetben

6 Modellelemzés

7 Fizikai tervezési fázis

8 Alapigények megvalósítása

Következtetés

Információforrások listája

Bevezetés

Számos cég és vállalkozás igényli a takarítócégek szolgáltatásait.

A takarítócég olyan cég, amely átfogó takarítási szolgáltatásokat nyújt. A lakossági, kereskedelmi és ipari helyiségek tisztítására és tisztaságának fenntartására tervezett intézkedések összessége, beleértve a homlokzatok tisztítását, a kirakatok és az épületek egyéb külső felületeinek mosását, egy nagyon összetett folyamat, amely sok különböző szakaszból áll, és számos részt vesznek. A takarítás megszervezésének eredményessége megköveteli a cselekvések egyértelmű koordinációját valamennyi alkalmazottja vonatkozásában.

A szakosodott cégek előnyét a következő tényezők határozzák meg:

· A szolgáltatások magas színvonala;

· A szolgáltatások költsége nem haladja meg a saját takarítási szolgáltatás fenntartásának költségét;

· A takarítócégek szolgáltatási költségeit le kell vonni az adóköteles nyereségből;

· A takarítócégek szakemberei exkluzív és összetett speciális munkákat végeznek (például - márványbevonatok kristályosítása);

· Hatékonyság – a tisztítást az Ügyfél számára megfelelő időpontban végezzük.

Ma a takarítás az egyik legdinamikusabban fejlődő és legstabilabb üzletág Oroszországban. Egyre több cég érdeklődik a minőségi és megbízható takarítási szolgáltatások beszerzése iránt, ami nagy követelményeket támaszt az ügyfelekkel való hozzáértő és kiegyensúlyozott munkavégzéssel szemben.

A fenti előnyök mindegyike megköveteli a modern információs technológiák alkalmazását a takarítócégek munkájában, például speciális információs rendszereket, például CRM-rendszereket.

Ügyfélkapcsolat-kezelő rendszer (CRM, CRM rendszer, a Customer Relationship Management rövidítése) egy olyan alkalmazásszoftver szervezetek számára, amelyek célja az ügyfelekkel (ügyfelekkel) folytatott interakciós stratégiák automatizálása, különösen az értékesítés növelése, a marketing optimalizálása és az ügyfélszolgálat javítása információk tárolásával. az ügyfelekről és a velük való kapcsolatok történetéről, az üzleti folyamatok kialakításáról és fejlesztéséről, majd az eredmények elemzéséről. A CRM rendszer minden olyan vállalkozásban alkalmazható, ahol az ügyfél megszemélyesítve van, ahol nagy a verseny, és a siker azon múlik, hogy az ügyfél számára a legkedvezőbb feltételeket biztosítsák - egy olyan interakciós modell, amely szerint a teljes üzleti filozófia középpontjában az ügyfél áll, és a fő tevékenységi területei a hatékony marketinget, értékesítést és ügyfélszolgálatot támogató intézkedések. Ezen üzleti célok támogatása magában foglalja a vevőkre, beszállítókra, partnerekre, valamint a vállalat belső folyamataira vonatkozó információk gyűjtését, tárolását és elemzését. Az ezeket az üzleti célokat támogató funkciók közé tartozik az értékesítés, a marketing és az ügyfélszolgálat.

Minden CRM-rendszer „szíve” egy olyan magánszemélyek és jogi személyek adatbázisa, amelyek a vállalkozás keretein belül kapcsolatba lépnek az Ön cégével. Ezek nem csak vevők, hanem a cég fiókjai, partnerei, beszállítói, versenytársai is. Az ügyfél-adatbázis önmagában is értékes eszköz, a CRM-rendszerben az intelligens adatkezelés pedig lehetővé teszi az információk maximális hatékonyságú felhasználását a munkája során. Az ügyfélkör megszilárdul, a szervezet teljes körű tájékoztatást kap ügyfeleiről és preferenciáikról, és ezek alapján kommunikációs stratégiát épít fel.

Az ügyfelek egyetlen adatbázisa és a velük fennálló kapcsolatok teljes története, a hatékony analitikus CRM-eszközökkel kombinálva lehetővé teszi a meglévő ügyfelek megtartását és fejlesztését, a legértékesebbek azonosítását, valamint új ügyfelek vonzását.

A CRM-rendszer fő funkciója, hogy segítse a vezetőket az értékesítés tervezésében, az átlátható ügyletkezelés megszervezésében és az értékesítési csatornák optimalizálásában. A rendszer eltárolja az ügyfelekkel való kommunikáció teljes történetét, amely segít az értékesítési osztályoknak elemezni a vásárlói magatartást, a számukra megfelelő ajánlatokat megfogalmazni, hűségszerzést. A CRM rendszerek többi képességét az alábbiakban mutatjuk be:

· Ügyfelekkel való kapcsolattartás tervezése, koordinálása;

· Az ügyfelekkel kapcsolatos összes lehetséges információ összegyűjtése és beírása;

· Hosszú távú vagy összetett ügyletek lebonyolításának ellenőrzése;

· A projektek végrehajtásának vagy a tranzakciók megkötésének egyes szakaszainak elemzése;

· Az ügyfelekkel való interakcióra összpontosító összes folyamat formalizálása.

Ez a fajta szoftver leginkább azoknak a szervezeteknek a megfelelő, amelyek hosszú távú és többlépcsős projektekkel rendelkeznek, amelyekben nagyszámú alkalmazott vagy több részleg vesz részt. Mivel az időegységre jutó megkötött szerződések száma csekély, minden tranzakció több napot, sőt hónapot is igénybe vesz. Ez azt jelenti, hogy minden projekt kizárólag egyéni megközelítést igényel. Ilyen körülmények között ügyelni kell a vásárlói hűségre. Ehhez nemcsak az egyéni megközelítésre van szükség, hanem szigorúan be kell tartani a kijelölt határidőket, a szerződési feltételeket, valamint az összes érintett munkavállaló összehangolt munkáját és pontosságát.

1. Elemző rész

A MAKS cégcsoport 2000-ben alakult. A fő tevékenység egy multidiszciplináris komplex szolgáltatási szektor. A MAKS Cégcsoport megalakulása óta a kínált szolgáltatások köre folyamatosan bővül. Ma a MAKS Cégcsoport a következő típusú szolgáltatásokat kínálja (1. ábra):

· Objektumok biztonsága, gyorsreagálású csapatok, irányítótermi biztonság, magánnyomozói szolgáltatások;

· A kiszolgált ingatlanobjektumok minél hatékonyabb és zavartalan működésének biztosítása;

· A meglévő biztonsági rendszerek előzetes elemzése;

· Helyiségek komplex takarítása.

Rizs. 1. A "MAKS" Vállalatcsoport szolgáltatási területei

A „MAX PROTECTION” a nem állami biztonság szférájával együtt fejlesztették ki. Objektumok biztonsága, gyorsreagálású csapatok, vezérlőtermi biztonság, magándetektív szolgáltatások, mindezt a standard szolgáltatáscsomag tartalmazza. Az osztály informatikai infrastrukturális szakembereket alkalmaz, akik részt vesznek a külföldi állampolgárok sürgősségi segítségnyújtásában, és ismerik az áruk és értéktárgyak kísérésének minden árnyalatát.

A gyakorlat azt mutatja, hogy a biztonságot nem csupán egyenruhás őrök jelentik, hanem a lehetséges veszélyek megelőzésére és elhárítására irányuló intézkedések egész sora. Ezeket az intézkedéseket a „MAX PROTECTION” integrált biztonsági rendszer tartalmazza, amelyet sok éves tapasztalattal rendelkező szakértők fejlesztettek ki.

Az ügyfelek számára a biztonság integrált megközelítése azt jelenti, hogy az összes biztonsági szolgálattal való kommunikáció egyetlen vállalkozón keresztül zajlik. A vállalat megszünteti annak szükségességét, hogy az ügyfelek koordinálják több független szervezet munkáját. Az egyetlen operatív központ jelenléte lehetővé teszi, hogy azonnal és hatékonyan reagáljon bármilyen vészhelyzetre.

A „MAKS PROKHRANA” folyamatosan fejleszti és új biztonsági koncepciókat fejleszt. Fejlett külföldi technológiákat vezetünk be munkánkba, és konkrét feladatokra saját megoldásokat fejlesztünk. Azonban még a legfejlettebb automatizált biztonsági rendszerek sem tudják teljesen kiszorítani az embert. Ezért kiemelt figyelmet fordítanak a "MAX PROTECTION" munkatársai professzionalizmusának javítására. A szakemberek rendszeresen járnak továbbképző tanfolyamokra, felkészültségüket belső auditok során tesztelik. A személyzet szigorú kiválasztása lehetővé teszi az emberi tényező befolyásának minimalizálását a "MAX PROTECTION" szolgáltatásaiban.

A "MAX PROTECTION" vezetőinek célja az ügyfelek egyéni megközelítése. A szakértők többszintű elemzést végeznek, és ennek eredményei alapján a leghatékonyabb megoldásokat kínálják az ügyfél biztonságának biztosítására. Ugyanakkor a „MAX PROTECTION” tevékenységi köre nem korlátozódik a magánügyfelekre. A dolgozók jól ismerik a közcélú létesítmények védelmét, és jól bizonyítottak ezen a területen.

A részleg hozzáállása az integrált biztonsági szolgáltatásokhoz páratlan, és minden helyzetben maximális hatékonyságot garantál.

A MAKS Ekspluatatsiya divízió több mint tíz éve működik a piacon. A fő feladat a kiszolgált ingatlanobjektumok minél hatékonyabb és zavartalan működésének biztosítása. Ugyanakkor nem játszik szerepet a létesítmény üzembe helyezésének elévülési ideje és a berendezés bonyolultsági szintjének jelentősége.

A "MAKS EKSPLUATATSIA" által kínált komplex szolgáltatás magában foglalja a berendezések és mérnöki rendszerek műszaki támogatását, valamint biztonsági javaslatokat. Ez a lista tartalmazza a karbantartási és egyéb tervezett és nem tervezett munkákat; tűzjelző és videó megfigyelő rendszerek tervezése és telepítése, valamint számos javítási és kivitelezési szolgáltatás. A "MAKS EKSPLUATATSIYA" ügyfelei teljes szolgáltatáscsomagot kapnak egy vállalkozótól, amely jelentősen csökkentheti a költségeket és megkönnyítheti a szolgáltatások közötti interakciót.

Ennek a részlegnek a szakemberei mindig készen állnak arra, hogy többféle lehetőséget kínáljanak az objektummal való munkavégzéshez, annak sajátosságaitól és az ügyfél kívánságaitól függően. Az egyéni megközelítés lehetővé teszi az ügyfél számára, hogy teljes kölcsönös megértésre számítson a vállalkozóval, és ennek eredményeként a legjobb minőségű eredményt érje el.

A modern világban a modern épületek berendezése és felszerelése egyre változatosabb és összetettebb. Ennek a divíziónak a fő célja átfogó épületfelügyeleti szolgáltatás nyújtása. Minden alkalmazott ismeri a tudomány és a technológia legmodernebb vívmányait, és a gyártók ajánlásainak és szabványainak megfelelően használja azokat. Ez az egyetlen módja annak, hogy egy bármilyen bonyolultságú objektum teljesítménye és biztonsága megfelelő szinten garantálható legyen.

A MAX CONSULTING divízió több mint 10 éve végez tanácsadást és auditálást a biztonság területén. Az osztály fő feladata a helyzet átfogó elemzése, valamint a fejlődési kilátások téves számítása, figyelembe véve a cég fennálló problémáit, valamint a vállalkozás egyedi jellemzőit.

A „MAX CONSULTING” munkatársai a meglévő biztonsági rendszerek előzetes elemzését végzik. Természetesen az ilyen munkákat az ügyfél alkalmazottaival szoros együttműködésben végzik, akik naprakészen hozzák az összes jellemzőt és segítenek figyelembe venni.

A cég tevékenységének auditálását magasan képzett szakemberek végzik, akik nemcsak azonosítani tudják a kritikus pontokat egy már használt rendszerben, hanem megoldásokat is kínálnak azok megszüntetésére. Minden tanácsadó egy időben szolgált a bűnüldöző szerveknél, és jelentős tapasztalattal rendelkezik Oroszországban és külföldön.

A „MAX CONSULTING” szakemberei emellett segítséget nyújtanak a válsághelyzetek kiküszöbölésében, az üzleti folyamatok hatékonyságának növelésében, valamint a vállalat információs rendszereinek és informatikai kockázatainak hatékony kezelésében.

A divízió tanácsadói a kölcsönösen előnyös kapcsolatok kiépítését tűzték ki maguk elé annak érdekében, hogy az ügyféllel hosszú távú együttműködést folytathassanak. A "MAX CONSULTING" könyvvizsgálói szolgáltatásokat, jogi szolgáltatásokat kínál ügyfeleinek a büntetőjog, a munkajog, az adójog és egyéb jogok területén.

A "MAX CLEANING" cég által nyújtott szolgáltatási kör a helyiségek takarítása. Oroszországban az első takarító cégeket 1992-1994-ben alapították. az első vegyesvállalatok megjelenésével együtt, amelyek akkoriban egyedüli fogyasztói voltak szolgáltatásaiknak. 2012-ben az oroszországi takarítási szolgáltatások piacának volumene pénzben kifejezve körülbelül 9 milliárd rubelt tett ki - 2011-ben a volumene 45 milliárd rubel volt, 2012 végén pedig a takarítási piacot már becslések szerint a következőre becsülték: 54 milliárd rubel. Az elmúlt, 2014-ben az orosz takarítási szolgáltatások piacának volumene az elemzők szerint mintegy 10-11 milliárd rubelrel nőtt, és tavaly év végén mintegy 65 milliárd rubelre rúgott.

A takarítási szolgáltatások legnagyobb régiói közé tartozik Moszkva, a Krasznojarszk Terület, a Tyumen régió, a Baskír Köztársaság, Szentpétervár és a Hanti-Manszi Autonóm Kerület. Moszkva 100-150 millió dollárt tesz ki a hazai takarítási piacból.

Szakértők szerint több mint 300 takarítócég működik a tőkepiacon. A vállalkozás mérete szerint nagyjából 4 nagy kategóriába sorolhatók.

· A legnagyobb szolgáltatók (több mint 500 alkalmazott) ~ 67%;

· Nagy operátorok (500 főig) ~ 15%;

· Közepes méretű operátorok (200 főig) ~ 7%;

· Kis üzemeltetők (50 főig) ~ 11%.

A szinte minden piaci szereplő által kifogástalanul nyújtott alapszolgáltatások sorába tartozik a napi komplex takarítás, valamint a függőleges felületek mosása is. Továbbá az összes takarítócég mintegy 93%-a kínál gránit, márvány, porcelán kőedény és kerámia csempe csiszolására és polírozására, valamint a szomszédos területek tisztítására, valamint az építési munkák és tüzek utáni helyiségek speciális tisztítására. A vizsgálatban részt vevő cégek mintegy 87%-a nyújt kiegészítő szolgáltatásokat és személyzetet, például csomagolókat, rakodókat és egyebeket, a takarítási piac szereplőinek 80%-a pedig szomszédos és belső területek, szemét és hó zöldítését is biztosítja ügyfelei számára. eltávolítás. A takarítócégek fő ügyfelei szupermarketek és bevásárlóközpontok, gyártó vállalatok, szállító- és raktártársaságok, egészségügyi és sportintézmények, irodai és üzleti központok, nagy nemzetközi és orosz cégek, bankok, kormányzati szervek, szállodakomplexumok, szórakoztató létesítmények (mozi, klubok) , kaszinó), vasútállomások és repülőterek.

Rizs. 2. A takarítási szolgáltatások fogyasztóinak szegmentálása

A piac leglemaradóbb szegmense, amint azt számos tanulmány is mutatja, az egészségügyi intézményekben végzett takarítás. Ezt az állapotot a kialakult szokások, az ilyen szervezeteknél létező szigorúbb szabványok és az általuk elfogadott speciális követelmények magyarázzák a takarítócégek alkalmazottai által végzett takarítással kapcsolatban.

A takarítócég kiválasztásának szempontjai: piaci tekintély, a nyújtott szolgáltatások költsége és köre, a munkavégzés során alkalmazott eszközök, technológiák és vegyszerek szintje, a személyzet képzettsége, valamint a takarítást ellenőrző rendszer.

A helyiségek takarítása ipari szükséglet a modern üzleti világban. A napi takarítás szerződéses alapon a cég meglehetősen fejlett területe. Az egyszeri takarítás megrendelésének és a helyiségek fix gyakoriságú takarítására vonatkozó szerződés megkötésének lehetősége, az ügyfél számára kényelmes munkarenddel, ma nagyon elterjedt tevékenység, amely nagy adatmennyiséget igényel és a legalkalmasabb információs rendszer tervezésének példája. A cég munkatársai nagy figyelmet fordítanak az elvégzett takarítás ellenőrzésére és minőségére. A nyitottság is fontos része a cég munkájának. Az ügyfélnek joga van tudni, hogy ez a "MAX CLEANING" cég mit, hogyan és annak segítségével mit csinál. Valamennyi vegyipari termék rendelkezik higiéniai tanúsítvánnyal, a partnerek és a vásárlók felkereshetik a gyártóbázist, megismerkedhetnek a vállalkozás technológiai adottságaival, munkaszervezésével.

A takarítás modern és igényes szolgáltatás, amelyet különböző helyiségek takarítására szakosodott cégek nyújtanak. Ezt a tisztítást speciálisan képzett dolgozók végzik, és a magas európai szabványok szerint értékelik.

A takarítás az 1990-es évek elején jelent meg Oroszországban, és mindenekelőtt a nagy nyugati vállalatok körében kezdett kereslet lenni, akik megszokták a professzionális takarítást hazájukban. A szolgáltatás a lakossági, kereskedelmi és ipari helyiségek tisztítására és tisztaságának fenntartására irányuló tevékenységek teljes skáláját egyesíti, beleértve a homlokzatok tisztítását, a kirakatok és az épületek egyéb külső felületeinek mosását. A szolgáltatások listája általában a tetőkről és a szomszédos területekről történő szemétszállítást és hóeltakarítást is tartalmazza.

Jelenleg az összes szolgáltatást szakképzett személyzet végzi a modern tisztítási technológiák alkalmazásával, a legújabb eszközökkel, amelyeket minden felületre külön-külön választanak ki, figyelembe véve annak fizikai, kémiai és műszaki jellemzőit. Az orosz takarítási piac jelentősen bővült, és további fejlődési kilátásai vannak. Néhány évtized múlva az emberek elfelejtik, mi az öntisztítás, és olyan céghez fordulnak, amely ezeket a szolgáltatásokat nyújtja. Valójában nem csak maga a megjelenés, hanem a tulajdonos egészsége is függ a szoba tisztaságától.

Számos kis- és nagyvállalat vezetőjének sikerült már meggyőződnie arról, hogy a szakcégek által kínált takarítás minőségileg jóval felülmúlja a szokásos értelemben vett takarítást. A professzionális tisztítás magában foglalja a helyiségek kifogástalan állapotba hozását, az ilyen tisztítás végső soron időt takarít meg, növeli a befejező anyagok élettartamát és növeli a vállalat presztízsét.

A cég alkalmazottai és vezetői egységes mechanizmusként dolgoznak, nemcsak a kínált szolgáltatások magas színvonalát értékelik, hanem elemzik a megrendelt szolgáltatásokat, előrejelzik a szolgáltatási piac helyzetét, és ennek eredményeként konstruktív megoldásokat kínálnak a vészhelyzetekre. helyzetek és a leghatékonyabb megoldások az ügyfél igényeire.

2003-ban az ügyfélszolgálat minőségének javítása érdekében új részleg megnyitásáról döntöttek, amely további professzionális takarítási szolgáltatásokat nyújt majd. A MAKS CLEANING Moszkvában tette meg első lépéseit. A fővárosban szerzett tapasztalatokat felhasználták a régiókba való belépéshez. És bár eleinte volt elég probléma, a cégnek sikerült megbirkóznia minden nehézséggel. 2005-ben a cég szerződést írt alá a METRO szupermarket lánccal, így az egyik első vállalat lett, amely szupermarketek és hipermarketek takarítási szolgáltatásokat nyújt. 2010-re a cég létszáma több mint 400 fő volt. A személyzet Moszkva egész területén dolgozik. 2012-re a MAX CLEANING belép Oroszország régióiba. Az első fiókokat Krasznojarszkban és Kazanyban nyitották meg. Az irodák és bevásárlóközpontok professzionális takarításának minősége meghaladja a regionális ügyfelek elvárásait. A cég 700 fős létszámmal már megközelítette fennállásának 10. évfordulóját. Minden további tapasztalat egyedülálló tudást adott a takarítás területén.

Nagy jelentősége van az elmúlt években megalakult MAX CLEANING cég hírnevének. Ehhez figyelembe kell venni az egyes alkalmazottak munkájához való hozzáállását.

Az ügyfelekkel való interakció és kommunikáció a siker elengedhetetlen összetevői. Nagyon fontos a vevőkkel kötött szerződések nyilvántartása, az ügyfelek minden olyan megrendelése, amely az ő igényeiket tükrözi.

A rugalmas árpolitika, az alkalmazottak professzionális képzése, a különféle berendezések és vegyszerek használata lehetővé teszi számunkra, hogy vezető pozíciót foglaljunk el ezen a szolgáltatási területen.

A takarító cég szolgáltatásait az Orosz Föderáció egész területén nyújtja. A szolgáltatási terület fő része az Orosz Föderáció központi része. A cég számos nagy jogi személlyel dolgozik együtt, az alábbi ábrán látható:

Rizs. 3. A "MAX-CLEANING" cégei-ügyfelei

.1 A vállalat szervezeti felépítése

A MAX CLEANING cég különböző részlegekből áll, amelyek különböző funkciókat és feladatokat látnak el, a MAX CLEANING cég szervezeti felépítését a 4. ábra mutatja.

Rizs. 4. Szervezeti felépítés

A főigazgató és helyettese irányítja a MAKS-CLEANING céget, amely számos részlegből áll, többek között:

· Ügyfelekkel foglalkozó osztály;

· Munkák osztálya.

Ügyfélszolgálati Osztály

A "MAX-CLEANING" cég ügyfeleivel folytatott munkaköre kiterjedt: fő feladata a jogi személyek hosszú távú együttműködése és kiszolgálása, igényeik, szintjük és fókuszuk elemzése. Tárgyalás az ügyfélcégekkel, a MAKS-CLEANING által nyújtott szolgáltatások értékesítési feltételeinek megismerése, a munkavégzés ellenőrzése - mindez az osztály munkájának szerves részét képezi.

Az ügyfélcég felveheti a kapcsolatot a "MAX-CLEANING"-el és igénybe veheti a helyiségek komplex takarításának szolgáltatásait. A cégvezető segít Önnek hosszú távú együttműködési megállapodás megkötésében, vagy egyszeri megrendelés feladásában. Ezenkívül köteles minden szükséges információt megtudni az ügyféltől, nevezetesen:

Információ az általa képviselt cégről;

Komplex takarítást igénylő ingatlanra (telephelyre) vonatkozó adatok;

Az ügyfél takarítási osztály választása;

Szolgáltatási feltételek;

Különleges megjegyzések a helyiségekkel való munkával kapcsolatban (Minden kapott információt a menedzser dolgoz fel, és szigorúan bizalmas).

Sikeres szerződéskötés vagy megrendelés esetén a szolgáltatás teljesítése a munkaosztályra száll, melynek feladata a takarítási szolgáltatások időben történő és minőségi biztosítása (végrehajtása).

Munkaosztály

Ez az osztály egy vezető művezetőből és portásokból áll, akik külön csapatokat alkotnak. A szerződés (megrendelés) cégvezető által a vezető művezető részére történő átadása után következik a takarítási munka elosztásának szakasza a takarítócsoport vezetői között.

Az ügyfél helyiségeinek takarítása a korábban megkötött szerződésben (megrendelésben) előírt határidőre történik. A szolgálat teljesítéséről jelentést adunk a főművezetőnek, aki értékeli minden egyes takarító munkáját, aki a takarítást végző brigádban van. Ezen túlmenően a vezető művezető vállalja, hogy a megbízás állapotáról értesíti a számlavezetőt.

Ezt követően a megbízó maga ellenőrzi a munka minőségét. Nem kielégítő értékelés esetén a vezető tájékoztatja a cégvezetést a megfelelő döntések meghozatala érdekében.

A „MAKS-CLEANING” cég fentebb ismertetett részlegei tevékenységének elemzése során az üzleti folyamat diagramja készült, amelyet az alábbi 5. ábra mutat be.

Rizs. 5. Üzleti folyamat "MAX-CLEANING"

Mindkét részlegnek gyors ügyfélszolgálatra és tranzakciókra van szüksége a dokumentumáramlás automatizálása, valamint a jelentési adatok és az elemző információk gyors fogadása révén, hogy időben és minőségi szolgáltatást nyújthasson.

1.2 Az ügyfélszolgálati részleg és a munkaosztály szoftverének és hardverének elemzése

Minden fiókkezelő rendelkezik egy személyi számítógéppel, telefonnal és különféle perifériákkal a szükséges információk kezelésére. A cég rendelkezik internet-hozzáféréssel, amelyhez minden MAKS-CLEANING alkalmazott hozzáfér. Minden számítógép fel van szerelve Windows 7-tel, a szükséges Microsoft Office csomaggal, beleértve az Access-t, valamint a számos HP DesktJet perifériával való együttműködéshez szükséges illesztőprogramokat. Az ügyfélszolgálati részleg és a munkaosztály szoftvere és hardvere a 6. ábrán látható.

Rizs. 6. A "MAX-CLEANING" cég szoftvere

A cég kliens-szerver koncepción alapuló hálózatot használ. A modern DBMS-ek esetében a kliens-szerver architektúra de facto szabvány lett.

A "kliens-szerver" technológia alapelve, hogy egy szabványos interaktív alkalmazás funkcióit négy csoportra osztja:

· Adatbeviteli és megjelenítési funkciók;

· A tárgykörre jellemző alkalmazott funkciók;

· Az erőforrások (adatbázisok) tárolásának és kezelésének alapvető funkciói;

· Szerviz funkciók.

Ennek a rendszernek az előnyei:

· A kiszolgálóprogram kódjának kliensprogramok általi megkettőzése.

· Mivel minden számítást a kiszolgálón hajtanak végre, csökkennek a követelmények azon számítógépekkel szemben, amelyekre az ügyfél telepítve van.

· Minden adatot egy szerver tárol, amely általában sokkal jobban védett, mint a legtöbb kliens. Könnyebb megszervezni a jogosultság ellenőrzését a szerveren, hogy csak megfelelő hozzáférési jogosultsággal rendelkező kliensek férhessenek hozzá az adatokhoz.

Az ügyfél tájékoztatást ad a cégvezetőnek, aki azt Microsoft Word 2010 programmal PC-jén rögzíti, kinyomtatja a szerződést (megrendelést) és a dokumentumot papíron tárolja. Így fennáll az összes szükséges információ elvesztésének veszélye, és felmerül az ügyfélről, telephelyéről és kapcsolatairól szóló további információk keresésének problémája. Ezenkívül a menedzser nem tudja automatikusan kiszámítani nemcsak a takarítás költségét, annak osztályától, a szoba méretétől és a szerződés szolgáltatási időszakától függően, hanem azt sem, hogy hány csapat szükséges az időben és magas szinten történő tisztításhoz. minőségi takarítás a szobában.

Az alapötlet az, hogy egy hálózati alkalmazást több komponensre kell felosztani, amelyek mindegyike egy adott szolgáltatáskészletet valósít meg. Egy ilyen alkalmazás összetevői különböző számítógépeken futhatnak, szerver és/vagy kliens funkciókat ellátva. Ez javítja a hálózati alkalmazások és a hálózat egészének megbízhatóságát, biztonságát és teljesítményét. Az általam a MAKS-CLEANING cég számára kifejlesztett információs rendszer modul segíti a vállalkozás jövedelmezőségének növelését az ügyfelekkel, értékesítési rendszerekkel kapcsolatos információk mélyreható elemzésével, lehetővé teszi a cég vezetése számára az elvégzett munka legfontosabb minőségi mutatóinak nyomon követését. szerződés alapján, amely a stratégiailag fontos üzleti döntések meghozatalához és az egyes munkavállalók munkájának hatékony értékeléséhez szükséges.

Végső osztályozó munkám célja egy információs rendszer modul kidolgozása a különböző helyiségek komplex takarításának elszámolására.

E cél eléréséhez a következő feladatokat kell végrehajtania:

Elemezze a "MAKS" cég tevékenységét a helyiségek tisztítására;

Készítsen egy listát az adatbázis-fejlesztés követelményeiről;

Adatbázis fejlesztése az ER-diagrams módszerrel és az Erwin CASE-eszközökkel;

Végezzen lekérdezéseket az adatbázisban lévő adatok kezeléséhez.

Az információs rendszer kidolgozott moduljának az alábbi követelményeknek kell megfelelnie:

· A szerződésekre vonatkozó adatok létrehozása és tárolása a szolgáltatási költség automatikus kiszámításával a szerződés időtartamára;

· Készítsen és tároljon adatokat a rendelésekről a takarítás költségének automatikus kiszámításával a helyiség méretétől és a takarítás osztályától függően;

· Napló adatok minden tisztításról;

· Tárolja a takarítás minőségével kapcsolatos információkat a brigád minden alkalmazottja számára;

· Számítsa ki a brigád értékelését a cégvezető számára;

· A helyiségek takarításához szükséges csapatok számának automatikus kiszámítása.

Feltételezem, hogy egy ilyen rendszer bevezetése megnöveli a takarítócég szolgáltatásaihoz szükséges összes dokumentum feldolgozásának sebességét, valamint csökkenti a hibák számát az ügyfelekkel való munka során.

A végső osztályozási munkában a kijelölt feladatok megoldásához a következőket kell használni:

· Adatbázis tervezési módszer - ER modellezés. Ez a témakör grafikus leírása a "tárgy - tulajdonság - kapcsolat" kifejezéssel. Az ER-modellezés alkalmazása számos előnnyel jár: fókuszáltabbá és specifikusabbá teszi a témakör elemzését; lehetővé teszi az AIS tervezését egy adott céladatbázis-rendszerre való hivatkozás nélkül, és az utóbbi bármikori kiválasztását; a használt DBMS megváltoztatásakor nem kell újra végrehajtania a tervezést, csak egy lépést kell tennie, hogy az ER-modellt átvigye a célmodellbe (ha az Ön által választott cél DBMS-t támogatja ez a CASE-eszköz, akkor az ilyen átmenet automatikusan megtörténik);

· CASE - Erwin eszköz. Előnye az adatbázis szerkezetéről diagramok készítésének lehetősége, amelyek automatikusan megoldják az integritásának megőrzésével kapcsolatos problémákat, valamint a logikai modell függetlensége a használt DBMS-től, ami lehetővé teszi univerzális módszerek alkalmazását adott DBMS-be exportálva.

· Az MS Access DBMS van kiválasztva cél DBMS-ként. Az Access egy relációs adatbázis-kezelő rendszer, amely minden szükséges eszközt tartalmaz a helyi adatbázis, a helyi hálózaton fájlszerverrel megosztott adatbázis vagy az SQL szerveren lévő adatbázis létrehozásához, valamint az ezekkel működő felhasználói alkalmazások létrehozásához. adatbázisok. Az Access DBMS különféle és számos, viszonylag önálló szoftvereszközt tartalmaz, amelyek adatbázis-objektumok és felhasználói alkalmazások létrehozására összpontosítanak. A grafikus tervező lehetővé teszi a felhasználó számára adatbázis- és alkalmazásobjektumok létrehozását számos grafikus elem felhasználásával, programozás nélkül.

2. Tervezési rész

.1 A témakör leírása

A cég Moszkvában saját járműparkkal rendelkezik, amely 5 VOLVO járműből áll, valamint minden járműhöz 6 fővel rendelt sofőrök tartoznak. Komplex helyiségtakarítást végző csapatok (3), egyenként 3 fős létszámban.

Céges szolgáltatások:

· Helyiségek komplex takarítása (kereskedelmi, ipari, raktári és ipari);

Az ügyfél, amely csak jogi személy lehet, a MAKS cég vezető beosztású alkalmazottjához jelentkezik megbízások átvételére. A cég szolgáltatásait mind az ügyfél kérésére, mind hosszú időn keresztül (7 naptól és tovább) nyújtja.

Az ügyfél a következőket beszéli meg a rendeléskezelővel:

Az ügyfél adatot szolgáltat a szolgáltatásra szoruló helyiségekről (helyiség típusa, területe, elhelyezkedése);

A rubelben mért árat a szerződés határozza meg (100% előleg):

Ø Az ügyfél kérésére (egyszeri) - a szoba területétől, a takarítás típusától és az érintett csapatok számától függ.

Ø Hosszú időn keresztül - a szolgáltatás időtartamától, gyakoriságától és a helyiség területétől függ.

Az ügyfél személyes adatai

Szobaadatok

Szolgáltatás időtartama

Az érintett csapatok száma

A szolgáltatás minőségét az ügyfél és a cég alkalmazottja ellenőrzi, aki figyelemmel kíséri a csapat munkájának eredményét. Az ügyfél és a munkavállaló egyező, nem kielégítő megítélése esetén a munkacsoport megrovásban részesül, egészen a felmondásig.

A cég flottája rendelkezésére álló autók kiválasztását a szállítás kiválasztásával foglalkozó szakember végzi. Felméri a munkacsoport célba szállításához szükséges helyiségek és járművek kiszolgálásához szükséges létszámot. A gépek kiválasztását a telephelyen megadott adatok után azonnal elvégzi a megrendelő a szerződéskötés előtt.

.2 Tervezési és megvalósítási módszerek megvalósíthatósági tanulmánya

A szolgáltató központ adatbázisának kialakításához az ER - diagram módszer alkalmazása mellett döntöttek. Ezt a tervezési módszert a következő tényezők alapján választottam:

Az ER-diagramok módszerét az Adatbázis tudományágában tanultuk meg.

Az ER - diagramokat használó tervezési módszernek számos előnye van, nevezetesen az áttekinthetőség; nagyszámú objektumot és attribútumot tartalmazó adatbázis tervezésének képessége;

Az ER diagramok lehetővé teszik a témakör pontosabb elemzését;

Az SQL nyelv ismeretére vonatkozó követelmények csökkennek.

Az ER-modell három elemen alapul:

Lényeg

Tulajdonság

Számítógépes adatbázis-tervező rendszerként az ERwin Data Modeler-t választottam.

DBMS-nek a Microsoft Access került kiválasztásra. Ezt a DBMS-t a következő tényezők alapján választottam ki:

A Microsoft Access-et a tanulmányaim alatt tanították;

Az Access gyors és egyszerű táblalekérdezések létrehozását teszi lehetővé;

Az adatok feldolgozásakor az Access az SQL lekérdezési nyelvet használja, amelyet szintén az Adatbázisok szakterületen tanítottak meg nekem.

.3 Adatbázis tervezés

Koncepcionális tervezési fázis

Az entitások leírása.

Az entitások kiválasztása.

Csatlakozások leírása.

A lényeg		A lényeg
Helyiségek	Biztosítani
	Szolgál	Alkalmazottak
	Szükséges (tartozék)
	Kitett
	Konzultál	Alkalmazottak
	Jelek
	Értékel
Alkalmazottak	Csókolózni
	Elfogadott
	Előadja
	Ellenőrzés
	Végezzen
	Lehetővé tesz

2.4 Fogalmi adatmodell a Chen szabványban

2.5 ER diagram ERwin környezetben

.6 Modellelemzés

Összetett attribútum: - nem

Többértékű attribútum: Telefon (cég, képviselő)

Származtatott attribútum:

Rendelés - költség = Takarítás típusa (költség) * Helyiség (terület)

Megállapodás - ár = Megállapodás (szolgáltatási időszak / gyakoriság) * Telephely (terület)

Rekurzív hivatkozások: - nem

1. kapcsolat: 1: A rendelés tisztítást igényel

Redundáns kapcsolatok: igen

A Társaság képviselőjének entitása megjelenik:

Az ügyfél konzultál a Munkavállalóval

Vevői árak Takarítás

· Az ügyfél aláírja a Szerződést

Az ügyfél megrendelést ad le

A helyiségeket az alkalmazottak szolgálják ki

A helyiségek takarítása folyamatban van

Az alkalmazottak végrehajtják a parancsot

Az alkalmazottak felügyelik a takarítást

A szerződés Takarításra kötelezi

Link m: n: igen

Az alkalmazottak takarítanak

Rizs. 8. Végső modell Erwinben

7 Fizikai tervezési fázis

Adatséma a kiválasztott DBMS környezetében

Rizs. 9. DB adatséma

2.8 Az alapvető kérések végrehajtása

adatbázis-manipuláció tisztítása

Rizs. 9. Alapigények megvalósítása

· A cég vezetőinek szerződéseinek listájának megjelenítése

Ez a kérés lehetővé teszi, hogy a felhasználót beléptető vezető személyi száma alapján megtekinthesse az általa kiadott szerződések listáját. Egy ilyen kérés lehetővé teszi, hogy gyorsan megtekintse az adott cégvezető munkájával kapcsolatos információkat.

Alkalmazottak.Tab_Szám, Alkalmazottak.Teljes név, Alkalmazottak.Telefon, Alkalmazottak.Pozíció, Alkalmazottak.Osztályszám, Szerződés.Szerződésszám FROM Alkalmazottak BELSŐ CSATLAKOZTATÁSI szerződése Alkalmazottak [Tab_Number = Szerződés. :)));

Tekintse meg a portás-művezetők munkájának értékelését

Ez a kérés a takarítócsoport-vezetők teljesítményértékelésének áttekintésére irányul. Az ügyfél és a cégvezető értékelése szerint észrevételek, intézkedések tehetők a takarítók munkájában bekövetkező további hibák megelőzésére.

[SELECT Employees.Full Name, Employees.Position, Cleaning.Evaluation_Client, Cleaning.Evaluation_Manager, Employees.Nom_Brigade FROM Cleaning INNER JOIN (Employees INNER JOIN Delete_Cotr ON Employees.Tab_Number) =Tisztítás_törlésebWCanumbering)

· Megrendelések listájának megjelenítése a megadott tisztítási típushoz

Ez a kérés lehetővé teszi az ügyfél által leadott rendelési adatok megtekintését.

SELECT [Cleaning type]. [Cleaning class], [Cleaning type]. Cost, Order.Order_number FROM [Cleaning type] INNER JOIN Order ON [Cleaning type]. [Cleaning class] = Order. [Cleaning class] WHERE (([ Tisztítás típusa] [Tisztítási osztály]) = [Adja meg a tisztítási osztályt:]);

Keressen céget - ügyfelet az adatbázisban

Ez a kérés lehetővé teszi a munkavállaló számára, hogy megadja az ügyfél cégének nevét, és megjelenítse a korábban teljesített szerződések és megbízások listáját, ha vannak ilyenek. Egy ilyen kérésnek köszönhetően elkerülhető lesz az ügyfél cégére vonatkozó adatok újbóli megadása.

SELECT Client [Cég neve], Ügyfél.Az Ön_címe, Ügyfél.Vállalat_telefonja, [Vállalat képviselője] Teljes név, [Cég képviselője] E-mail FROM Client INNER JOIN [Cég képviselője] ON Client.CL = [Cég képviselője] . CL WHERE ( ((Ügyfél. [Cégnév]) = [Adja meg a cég nevét:]));

Keressen befejezetlen / teljesített rendeléseket

Ez a kérés lehetővé teszi, hogy megjelenítse a teljesített és nem teljesített rendelések listáját a felhasználó által megadott állapot szerint.

SELECT Rendelés.Rendelési_szám, Megrendelés.Állapot, Rendelés.Fogadási_dátum, Rendelés [Tisztítási osztály], Rendelés.Teljesítési_dátum FROM Rendelés WHERE (((Rendelés.Állapot) = [A rendelés állapota:]));

Helyiségek listája típusonként

Ez a kérés lehetővé teszi, hogy megjelenítse a megadott helyiségek listáját

a felhasználó által a helyiség típusára.

SELECT Rooms.Address, Rooms.Area, Rooms.Type, Rooms.CL FROM Rooms WHERE (((Rooms.Type) = [Adja meg a szoba típusát:]));

A 30 napot meghaladó szerződések listája

Ez a kérés lehetővé teszi azon szerződések listájának megjelenítését, amelyek szolgáltatási ideje meghaladja a 30 napot.

SELECT Szerződés.Név_szerződés, Szerződés.Rendelés_dátuma, Szerződés.Cím, Szerződés [Szolgáltatási idő (napok)] FROM szerződés WHERE (((Szerződés. [Szolgáltatási idő (nap)])> 30));

A rendelések értékének kiszámítása

Ez a kérés lehetővé teszi a rendelés költségének megjelenítését a felhasználó által megadott számmal. Egy ilyen kérésnek köszönhetően elkerülhetők a hibák a rendelések értékének kiszámításakor.

SELECT Rendelési_szám, ([Tisztítás típusa]. [Költség] + [Tisztítás típusa]. [Dandárok száma területegységenként]) * [Termékek]. [Terület] AS Rendelési_érték, Rendelés. [Tisztítási osztály], Megrendelés. Állapot FROM Rooms INNER JOIN ([Cleaning type] INNER JOIN Order ON [Cleaning type]. [Cleaning class] = Order. [Cleaning class]) ON Rooms.Address = Order.Address WHERE (((Rendelés.Rendelési_szám) = [Rendelés megadása) szám:]));