Belső interakció a megrendelővel a tervezés során. Megrendelő és Vállalkozó – kapcsolatok, mint a projekt sikerének alapja

Az ügyféllel való interakció általános szakaszai a következők:

• - Előzetes kommunikáció a megrendelővel: a projekt céljainak és célkitűzéseinek meghatározása, a leendő rendszer főbb követelményeinek meghatározása, a Megrendelő cégével való előzetes megismerkedés, a projekt ütemezésének és költségének előzetes felmérése, Kereskedelmi ajánlat elkészítése és átadása az Ügyfélnek.
• - Vevői igények részletes felmérése, összegyűjtése: a projektcsapat összetételének meghatározása, a rendszer követelményeinek összegyűjtése, a Megrendelő kulcsfelhasználóinak és műszaki szakembereinek megkérdezése, a Feladatkör kidolgozása és elfogadása.
• - A rendszer fejlesztése és tesztelése: a rendszer, illetve funkcionalitása egy részének fejlesztése után bemutatóra kerül sor az Ügyfél számára. Ezt követi a hibák feltárásának és kiküszöbölésének szakasza, ha nincs, akkor az átvételi tesztek.
• - A rendszer próbaüzeme: a rendszer kiépítése Megrendelői oldalon, felhasználói oktatás, észrevételek, javaslatok gyűjtése a rendszer fejlesztésére, észrevételek megszüntetése.
• - A rendszer ipari működtetése: a Megrendelő önálló üzemeltetése, a Társaság ügyfélszolgálatának megkeresése (szükség esetén), a rendszer fejlesztésére vonatkozó kívánságok összegyűjtése.

Az ügyféllel való interakció fontos formája a projekt végrehajtása során a GOST 34 és a RUP követelményeinek megfelelően kidolgozott dokumentáció.

Konkrét projektfeladatokhoz munkacsoportokat alakítanak ki. Az akciók szinkronizálása a munkacsoportok küldötteiből álló tanácson keresztül történik. A munkacsoportok tagjai önállóan alakítják ki a csoportban való interakció elveit. A csoportok bevonhatják más csoportok tagjait a problémák megoldásába. A sikeres interakciós formákat mind a csoporton belül, mind a csoportok között átvehetik a projekt új résztvevői

A világ már régóta felismerte, hogy a projektmenedzsment egy speciális menedzsment terület, amelynek alkalmazása kézzelfogható eredményeket hoz. Az ezen a területen dolgozó szakembereket nagyra értékelik (az USA-ban ez a harmadik legjobban fizető szakma az ügyvédek és orvosok után), és maga a projektmenedzsment módszertana vált de facto vezetési standardtá sok ezer vállalkozásban, és különböző mértékben alkalmazzák szinte az összes nagyvállalat. Tavaly elfogadták az ANSI projektmenedzsment szabványokat, és kidolgozták az ISO 10006 projektmenedzsment szabványok tervezetét.

Ma már nem képzelhető el az összetett szoftveralkalmazások létrehozásának folyamata életciklus-szakaszokra bontás nélkül. A program életciklusa alatt a szakaszok összességét értjük:

• A témakör elemzése és műszaki specifikációk elkészítése (interakció a megrendelővel)
• Programstruktúra kialakítása
• Kódolás (programkódkészlet a projektdokumentáció szerint)
• Tesztelés és hibakeresés
• Program végrehajtása
• Program támogatás
• Ártalmatlanítás

Nézzük meg közelebbről a tervezési folyamatot. A tervezési folyamat során egy építész vagy egy tapasztalt programozó elkészíti a projektdokumentációt, beleértve a jövőbeli program szöveges leírásait, diagramjait és modelljeit. Ebben a nehéz kérdésben az UML nyelv a segítségünkre lesz.

Az UML egy grafikus nyelv különféle rendszerek (különösen programok) megjelenítésére, paraméterek leírására, tervezésére és dokumentálására. A diagramok olyan speciális CASE eszközökkel készülnek, mint a Rational Rose (http://www-01.ibm.com/software/rational/) és az Enterprise Architect (http://www.sparxsystems.com.au/). Az UML technológia alapján egyetlen információs modell épül fel. A fenti CASE eszközök különféle objektum-orientált nyelveken képesek kódot generálni, és nagyon hasznos visszafejtési funkcióval is rendelkeznek. (A visszafejtés lehetővé teszi grafikus modell létrehozását a meglévő programkódból és a hozzá fűzött megjegyzésekből.)

Fontolja meg a diagramok típusait a modell megjelenítéséhez (ezek kötelezőek, bár sokkal több típus létezik):

Használja az esetdiagramot

A megtervezett rendszer a rendszerrel úgynevezett precedensek segítségével interakcióba lépő entitások vagy szereplők halmazaként jelenik meg. Ebben az esetben a szereplő (szereplő) vagy szereplő bármely entitás, amely kívülről lép interakcióba a rendszerrel. Más szavakkal, minden használati eset meghatároz egy bizonyos műveletsort, amelyet a rendszer végrehajt, amikor egy szereplővel beszél. Arról ugyanakkor nem esik szó, hogy a szereplők interakciója a rendszerrel hogyan valósul meg.

Osztálydiagram (osztálydiagram)

Az osztálydiagram a rendszermodell statikus szerkezetének ábrázolására szolgál az objektumorientált programozási osztályok terminológiájában. Az osztálydiagram különösen tükrözheti a témakör egyes entitásai, például objektumok és alrendszerek közötti különféle kapcsolatokat, valamint leírja azok belső struktúráját (mezők, módszerek ...) és a kapcsolatok típusait (öröklődés, interfészek megvalósítása). ..). Ez a diagram nem ad információt a rendszer működésének időbeli vonatkozásairól. Ebből a szempontból az osztálydiagram a tervezett rendszer fogalmi modelljének továbbfejlesztése. Ebben a szakaszban elengedhetetlen az OOP megközelítés és a tervezési minták ismerete.

Állapotdiagram (statechart diagram)

Ennek a diagramnak a fő célja az állapotok és átmenetek lehetséges sorozatainak leírása, amelyek együttesen jellemzik egy modellelem viselkedését az életciklusa során. Az állapotdiagram az entitások dinamikus viselkedését ábrázolja, bizonyos konkrét események észlelésére adott válaszuk specifikációja alapján.

Sorozat diagram

Megfelelő interakciós diagramokat használnak az objektumok interakciójának modellezésére az UML nyelven. Az objektumok interakciói időben figyelembe vehetőek, majd egy szekvenciadiagram segítségével ábrázoljuk az objektumok közötti üzenetek továbbításának és fogadásának időzítését. A kölcsönhatásban lévő objektumok bizonyos információkat cserélnek egymással. Ebben az esetben az információ teljes üzenet formájában történik. Más szóval, bár az üzenetnek információtartalma van, elnyeri azt a járulékos tulajdonságot, hogy irányított befolyást gyakorol a címzettre.

Együttműködési diagram

Az együttműködés diagramján az interakcióban részt vevő objektumok téglalapok formájában jelennek meg, amelyek tartalmazzák az objektum nevét, osztályát, és esetleg attribútumértékeket. Az osztálydiagramhoz hasonlóan az objektumok közötti asszociációkat különféle összekötő vonalak jelzik. Ebben az esetben kifejezetten megadhatja a társítások nevét és az objektumok szerepét ebben a társításban.
A szekvenciadiagrammal ellentétben az együttműködési diagram csak az interakcióban bizonyos szerepet játszó objektumok közötti kapcsolatokat ábrázolja.

Alkatrész diagram

A komponens diagram a korábban tárgyalt diagramoktól eltérően a rendszer fizikai ábrázolásának jellemzőit írja le. Az alkatrészdiagram lehetővé teszi a fejlesztés alatt álló rendszer architektúrájának meghatározását a szoftverkomponensek közötti függőségek létrehozásával, amelyek lehetnek forráskódok, binárisok és végrehajtható kódok. Sok fejlesztői környezetben egy modul vagy komponens egy fájlnak felel meg. A modulokat összekötő pontozott nyilak hasonló függőségi kapcsolatokat mutatnak, mint a program forráskódja fordításakor. A komponensdiagram fő grafikus elemei az összetevők, az interfészek és a köztük lévő függőségek.

Beépítési diagram

A telepítési diagram célja, hogy megjelenítse a program azon elemeit és összetevőit, amelyek csak a végrehajtás szakaszában (futási időben) léteznek. Ebben az esetben csak azok a programpéldány-összetevők jelennek meg, amelyek végrehajtható fájlok vagy dinamikus könyvtárak. A futás közben nem használt összetevők nem jelennek meg a telepítési diagramon.
A telepítési diagram a processzorok, eszközök, folyamatok és a köztük lévő kapcsolatok grafikus ábrázolását tartalmazza. A logikai ábrázolási diagramoktól eltérően a telepítési diagram a rendszer egészére nézve ugyanaz, mivel teljes mértékben tükröznie kell a megvalósítás jellemzőit. Ez a diagram lényegében egy adott szoftverrendszer OOAP folyamatát fejezi be, és ennek fejlesztése általában a modellspecifikáció utolsó lépése.

Ezzel véget is értünk a diagramokról és általában a tervezésről szóló áttekintésünknek. Érdemes megjegyezni, hogy a tervezési folyamat már régen szoftverfejlesztési standard lett, de sokszor egy szépen megírt programmal kell számolni, amely a megfelelő dokumentáció hiánya miatt felesleges mellékfunkcionalitásra tesz szert, mankóvá válik, nehézkessé válik, elveszíti erejét. korábbi minőség. =(

Meggyőződésem, hogy a programozó elsősorban kódoló - NE kommunikáljon az ügyféllel, NE gondolkodjon a rendszer architektúráján, ne találjon ki interfészt a programhoz, csak kódoljon - algoritmusokat, funkcionalitást, megjelenést valósítson meg, használhatóság, de nem több… A tervezőnek az absztrakt diagramoktól kezdve (a tárgyterületet leíró) az adatstruktúrát, osztályokat és interakciójuk folyamatait bemutató diagramokig mindent lépésről lépésre részletesen le kell írnia. Vagyis egy tervező munka bonyolultsága és fizetése egy nagyságrenddel nagyobb legyen, mint egy programozóé == kódolóé. Elnézést a szóváltásért....

1.1. Interakció az ügyfelekkel (Fő funkciók)

1.1.1. Megrendelés keresése

7.2.3.1. Termékinformációkért

1.1.2. Előzetes munka a Megrendelővel

Szabályozó dokumentumok

2.2.1.2.1. Szerződéskötés előtti munka a Megrendelővel STP-1-01

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

7.2.1.1. Vevői követelmények a termékekre vonatkozóan, beleértve a rendelkezésre állásra, szállításra és karbantartásra vonatkozó követelményeket

7.2.2.4. Bizonyos követelményeknek való megfelelés képességének meghatározása

// Termékigény elemzése / Fogyasztóval kapcsolatos folyamatok / TERMÉKEK ÉRTÉKESÍTÉSE

1.1.3. A feladatmeghatározás kialakítása

Szabályozó dokumentumok

2.2.1.2.2. A szerződés elemzésének és megkötésének eljárása STP-2-01 // Az Enterprise Enterprise Ellat (STP) szabványai / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

7.2.1.2. A megrendelő által nem meghatározott, de a rendeltetésszerű vagy meghatározott felhasználáshoz szükséges követelmények // Vevői igények meghatározása / Vevővel kapcsolatos folyamatok / TERMÉKELADÁS

7.2.1.3. Termékkel kapcsolatos kötelezettségek, beleértve a kötelező követelményeket és a jogi rendelkezéseket // Vevői igények meghatározása / Vevővel kapcsolatos folyamatok / TERMÉKELADÁS

// Termékigény elemzése / Fogyasztóval kapcsolatos folyamatok / TERMÉKEK ÉRTÉKESÍTÉSE

7.2.2.2. Fogyasztói igények elfogadása előtti megerősítése, ha a fogyasztó nem ad írásbeli követelménynyilatkozatot // Termékigény elemzése / Fogyasztóval kapcsolatos folyamatok / TERMÉKEK ÉRTÉKESÍTÉSE

7.2.2.3. A szerződés vagy megrendelés követelményeiben bekövetkezett olyan változások tisztázása, amelyek eltérnek a korábban benyújtottaktól (például ajánlattétel vagy linkek útján) // Termékigény elemzése / Fogyasztóval kapcsolatos folyamatok / TERMÉKEK ÉRTÉKESÍTÉSE

7.3.1.1. A tervezési és/vagy fejlesztési folyamatok szakaszainak meghatározása

7.3.2.2. Alkalmazandó jogi és szabályozási követelmények

7.3.2.3. Az alkalmazható adatok hasonló korábbi fejlesztésekből származnak // Bemeneti adatok tervezéshez és fejlesztéshez / Tervezés és fejlesztés / TERMÉKELADÁS

7.3.2.4. A tervezés és fejlesztés szempontjából fontos egyéb követelmények // Bemeneti adatok tervezéshez és fejlesztéshez / Tervezés és fejlesztés / TERMÉKELADÁS

7.3.4.1. A követelmények teljesítésének képességének felmérése

1.1.4. Megállapodások megkötése

Szabályozó dokumentumok

2.2.1.2.3. A Megrendelővel kötött szerződéses munka szabályzata (STP-3-01) // Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

1.1.5. Szerződéses kötelezettségek teljesítésének figyelemmel kísérése

Szabályozó dokumentumok

2.2.1.2.3.2. A módosítások elemzésének és a szerződéses dokumentumok módosításának eljárása // A Megrendelővel kötött szerződéses munka szabályzata (STP-3-01) / Enterprise Standards Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

2.2.1.2.4.1. Az Ügyfél panaszainak és követeléseinek kezelési rendje

2.2.1.2.4.2. Az Ügyfél észrevételeinek törlésének eljárása // Korrekciós és megelőző intézkedésekről szóló szabályzat (STP-4-01) / Ellat Enterprise Standards (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

7.2.3.2. Kérelmek, szerződések, megrendelések feldolgozása, beleértve a változtatásokat is // Kommunikáció a fogyasztóval / Fogyasztóval kapcsolatos folyamatok / TERMÉKEK ELADÁSA

1.2. Projektmunka ütemezése (fő funkciók)

1.2.1. A komplexum összetételének és fejlesztési körének tisztázása

Szabályozó dokumentumok

// Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

7.2.2.1. A termékkövetelmények meghatározása // Termékigény elemzése / Fogyasztóval kapcsolatos folyamatok / TERMÉKEK ÉRTÉKESÍTÉSE

1.2.2. Projekt minőségbiztosítási tervezés

Szabályozó dokumentumok

2.2.1.2.5. A projekt minőségbiztosítási programjának összetétele és eljárása (STP-5-01) // Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

• 7.1.1. Minőségi célok kitűzése egy termékre, projektre vagy szerződésre

7.1.3. A felülvizsgálati és jóváhagyási tevékenységek és az elfogadási kritériumok meghatározása // Értékesítési folyamatok tervezése / TERMÉKEK ÉRTÉKESÍTÉSE

7.2.2.5. Az elemzés eredményeinek rögzítése és az azt követő nyomon követési intézkedések (lásd az 5.5.7. pontot) // Termékigény elemzése / Fogyasztóval kapcsolatos folyamatok / TERMÉKEK ÉRTÉKESÍTÉSE

7.3.1.2. A felülvizsgálati, ellenőrzési és jóváhagyási tevékenységek meghatározása minden tervezési és/vagy fejlesztési szakaszhoz // Tervezés és fejlesztés tervezés / Tervezés és fejlesztés / TERMÉKELADÁS

1.2.3. Magán műszaki specifikációk kialakítása a komplexum komponenseinek fejlesztéséhez

Szabályozó dokumentumok

2.2.1.2.7. Projekt megvalósítási technológia. A munka szakaszai és sorrendje (STP-7-01) // Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

1.2.4. Projekt tervezés

Szabályozó dokumentumok

// Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

7.1.2. A folyamatok és a dokumentáció kialakításának szükségességének meghatározása, a termékspecifikus erőforrások és infrastruktúra biztosítása // Értékesítési folyamatok tervezése / TERMÉKEK ÉRTÉKESÍTÉSE

1.2.5. A munkavégzés koordinálása, operatív ellenőrzése

Szabályozó dokumentumok

2.2.1.2.4.3. Korrekciós intézkedési eljárás // Korrekciós és megelőző intézkedésekről szóló rendeletek (STP-4-01) / Ellat Enterprise Enterprise Standards (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

2.2.1.2.6. rendelet a munkatervezésről (STP-6-01) // Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

7.3.4.2. Problémák azonosítása és javaslatok kidolgozása nyomon követési intézkedésekre // Tervezés és fejlesztés elemzése / Tervezés és fejlesztés / TERMÉKKEZELÉS

7.3.7. Tervezés és fejlesztés változásmenedzsment

1.3. Tervezés, szoftver és üzemeltetési dokumentáció fejlesztése (Fő funkciók)

1.3.1. A komplexum hardverének dokumentációjának kidolgozása

Szabályozó dokumentumok

2.2.1.2.7. Projekt megvalósítási technológia. A munka szakaszai és sorrendje (STP-7-01) // Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

2.3.3.3. A hardverfejlesztési és gyártási osztály munkaterve

1.3.2. A komplexum szoftver részének fejlesztése

Szabályozó dokumentumok

2.2.1.2.7. Projekt megvalósítási technológia. A munka szakaszai és sorrendje (STP-7-01) // Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

2.3.3.4. Szoftverfejlesztési és gyártási osztály munkaterve // Programok és akciótervek / A társaság szervezeti és adminisztratív dokumentumai / Szabályzat

1.3.4. A tervezési eredmények elemzése és jóváhagyása

Szabályozó dokumentumok

2.2.1.2.7. Projekt megvalósítási technológia. A munka szakaszai és sorrendje (STP-7-01) // Vállalati szabványok Ellat (STP) / Minőségirányítási rendszer dokumentumai / Belső szabályozó dokumentumok / Szabályzat

ISO9000:2000 minőségirányítási rendszer követelményeinek 7. pontja

7.3.3.1. Megfelel a tervezési és fejlesztési bemeneti követelményeknek

7.3.3.2. Adja meg a megfelelő információkat a gyártási és szolgáltatási műveletekhez (lásd a 7.5. pontot) // Tervezési és fejlesztési output / Tervezés és fejlesztés / TERMÉK PONTOZÁSA

7.3.3.4. Határozza meg a termék azon jellemzőit, amelyek elengedhetetlenek a biztonságos és megfelelő használathoz. // Tervezési és fejlesztési output / Tervezés és fejlesztés / TERMÉK PONTOZÁSA

7.3.5.1. A kimeneti adatok megfelelősége a bemeneti követelményeknek // Tervezés és fejlesztés ellenőrzése / Tervezés és fejlesztés / TERMÉKELADÁS

7.3.6. Tervezési és fejlesztési eredmények jóváhagyása // Tervezés és fejlesztés / ÉRTÉKESÍTÉSI TERMÉKEK

• Oktatás, Fejlesztés, Képzések

Kulcsszavak:

1 -1

Tekintsük az ügyféllel való interakció teljes sémáját a webhelyfejlesztés példáján. Grafikusan az interakció szakaszai a következő ábrával ábrázolhatók:

Az elsődleges az hívás vagy email, amelyeket a számlavezető dolgoz fel. A menedzser beszél a Beehive cég szolgáltatásairól, választ ad minden érdeklõdõ kérdésre, és elmagyarázza az ügyfélnek az interakció további folyamatát.

* Érdemes megjegyezni, hogy az ügyfél a projekt teljes időtartamára személyes menedzsert kap, aki kész válaszolni minden kérdésre, és segít minden probléma megoldásában.

Ezután a menedzser segít befejezni rövid forma az együttműködés témájában szükséges tisztázó kérdéseket tartalmazó, valamint a belső CRM rendszerhez (Customer Relationship Management System) elérhető kapcsolattartót tartalmazó weboldal kialakításához.

Az adatok az összes szükséges ügyféladat biztonságos tárolása és az oldal egészének minőségi fejlesztése érdekében kerülnek a rendszerbe.

Az elkészült tájékoztató alapján a Méhkas szakemberei készülnek egyedi kereskedelmi ajánlat a munka ütemezésének és költségének leírásával, és a vezető megküldi a megrendelőnek megfontolásra.

Ezután következik az együttműködés feltételeiben való megegyezés folyamata, aminek az eredménye szerződés. A munka megkezdésének felgyorsítása érdekében a szerződést mindkét fél aláírja, és a felek kicserélik a szerződés szkennelt másolatait. A szerződés eredeti példányait ajánlott levélben küldjük meg (a továbbiakban minden papíralapú másolat cseréje postai úton vagy futárral történik). Miután a fél átvette az eredeti példányt papíron, egy példányt postán küldenek vissza.

*A folyamat a hívástól a szerződés aláírásáig általában nem tart tovább 1-2 napnál.

A szerződés aláírása és az elektronikus szkennelt másolatok cseréje után a megrendelő előleget fizet, melynek összege általában a szerződés teljes összegének 50%-a.

Az előleg beérkezése és a témakör elemzése után kezdődik a fejlesztés és jóváhagyás szakasza feladatmeghatározás (TOR), ahol minden követelményt előírnak a fejlesztés alatt álló oldallal szemben, megadják a sémákat és elkészítik a teljes oldal részletes prototípusát. A TK a szerződés kötelező melléklete, amelyet mindkét fél jóváhagyott, és a szerződéssel azonos módon aláírt.

* Meg kell érteni, hogy a feladatmeghatározás nagyon fontos dokumentum mind a vállalkozó, mind a megrendelő számára. Lehetővé teszi egy internetes projekt tervezését és végrehajtását kiváló minőségben és időben.

Az összes követelmény jóváhagyása után az ügyfél elküldésre kerül a szükséges szöveges és grafikai anyagok listája, amelyet a megrendelőnek a fejlesztési szakasz megkezdése előtt kell biztosítania (azaz a kivitelező által a tervrajz kidolgozása során a megrendelő összegyűjti és biztosítja az összes szükséges anyagot). Ez a lista a következőket tartalmazhatja: a cég leírása, kikkel működnek együtt, milyen díjakkal és tanúsítványokkal rendelkeznek, árak és árlisták, termékkatalógus és áruleírás, szolgáltatások leírása, az oldalon közzétett elérhetőségek stb.

Néha az ügyfélnek nehéz leírni a szolgáltatásait, vagy egyszerűen nincs rá ideje. Ebben az esetben a vállalkozó készen áll a hiányzó tartalom (képek, szövegek, videók stb.) megírására.

* Az ügyfélnek a szükséges anyagokkal való ellátása kritikus, mert:

• az ügyfél által biztosított összes tartalmat egyszerre helyesen be kell írni az oldal elrendezésébe (nincs értelme többletmunkát végezni);
• az előadó technológiai folyamata szó szerint "percenként" ütemezett, és nem akarjuk megsérteni és többletköltségeket vállalni;
• Egy internetes projekt tesztinformációkkal való kitöltése szintén értelmetlen (egyrészt ismét megnő a felesleges munka mennyisége; másodszor, a keresőmotorok pesszimistaíthatnak egy hostolt oldalt teszttartalommal; harmadszor, potenciális vásárlói negatívan viszonyulhatnak az oldalhoz, ami nyilvánvalóan haszontalan információkat tartalmaz);
• Mind Önnek, mind nekünk fontos, hogy a projektet szakszerűen és időben fejezzük be.

* Kedves Ügyfeleink, kérjük, ne késlekedjenek saját oldaluk fejlesztésével, és profitáljanak belőle. Adj tartalmat időben! Ellenkező esetben a projektet befagyasztjuk mindaddig, amíg tájékoztatást nem kapunk Öntől, és ennek megfelelően az oldal beküldési határideje elhalasztásra kerül. Ha nincs időnk információt gyűjteni és írni, szövegírást és fotófeldolgozást rendelni hozzánk, akkor olcsó.

Ezzel párhuzamosan létrejön a projekt munkacsoportja, és elindul a szakasz tervezési elrendezés kidolgozása jövőbeli webhely.
Miután a tervrajz elkészült, jóváhagyásra elküldjük az ügyfélnek. A jóváhagyást követően a makett érvényes tervvé válik.

* A projekt összetettségétől függően az ügyfél hozzáférést kaphat a projektmenedzsment rendszerhez (például Redmine), ahol feltöltheti a szükséges projekt erőforrásokat, figyelemmel kísérheti a fejlesztési szakaszokat és megjegyzéseket tehet közzé.

A munka további folytatásához kötelező a megrendelőtől minden szükséges anyagot átvenni, amelyek listáját korábban elküldtük a megrendelőnek.

Amint a hiányzó anyagok beérkeznek. Egy fontos oldal fejlesztési szakasza a jóváhagyott TOR szerint.
Ez a szakasz számos munkatípust tartalmaz: ez a webhely-elrendezések böngészők közötti elrendezése, a kiválasztott tartalomkezelő rendszerhez (CMS) szükséges tervezési sablonok kidolgozása, magának a CMS-nek a telepítése és konfigurálása, a szükséges felszerelések telepítése. modulok és összetevők, hiányzó modulok fejlesztése, a webhely működési algoritmusainak átfogó tanulmányozása, a webhely tartalommal való feltöltése, a projekt telepítése a műszaki területen és továbblépés a tesztelésre.

Az internetes projekt tesztelését a kivitelező szakemberei végzik, minden hibát, észrevételt kiküszöbölnek, az oldalt munkára finomítják.

Amint a munka befejeződik és a webhely tesztelése a műszaki területen befejeződik, a átadási szakasz. Itt a megrendelő részéről a TOR követelményeinek teljesítését és az Internet projekt működésének teljes folyamatát ellenőrzik.
Miután az ügyfél döntést hoz arról, hogy az oldal teljes mértékben megfelel-e a TOR követelményeinek, az oldal átkerül az ügyfélhez, és a projektet közzéteszik a tárhelyen.

A munkák átadás-átvételének eredménye és igazolása egy működőképes helyszín és egy átvételi okirat, amelyet mindkét fél aláír. Az aláírt okiratot a teljes könyvelési dokumentumkészlettel együtt postai úton küldik el.

Az átvételi okirat aláírása után a megrendelő a szerződésben foglaltaknak megfelelően kifizeti a munka fennmaradó költségét.

A végső számítást követően a dokumentumokkal és a weboldallal együtt a vásárló egy használati útmutatót kap, az oldal másolata DVD-nés ingyenes technikai támogatás az oldal elfogadásától számított 2-4 héten belül.

Ezen a diagramon igyekeztünk teljes mértékben tükrözni az interakciók minden aspektusát a kezdeti felhívástól a projekt megvalósításáig. Egyszerű projektek esetén egyes lépések kombinálhatók vagy elhagyhatók. De mindenesetre minden benne van a szerződésben.

Az „Átfogó webhelyfejlesztés”, valamint a „Webhely-promóció” szolgáltatások munkaterve szerkezetileg megismétli a fent leírt ügyfél és vállalkozó közötti interakció folyamatát, ezért nem igényel részletes leírást.

Reméljük, hogy a leírt interakciós séma átlátható és érthető. Ha van még kérdése, kérem

Projekt:	Lekérdezések elosztása az elektronikus katalógusban keresési indexek és keresőkifejezések szerint
Projekt hatóköre:	13.02.2006 - 05.06.2006
Vevő:	A Petrozsényi Állami Egyetem Tudományos Könyvtára.
Felelős:	Gorshkova Galina Anatoljevna, a dokumentumok számítógépes feldolgozásával és a katalógusok létrehozásával foglalkozó osztály vezetője. Email posta: . Rabszolga. tel.: 719602. Könyvtár: cab. 102. Guryev Dmitry Borisovich, az RCNIT vezető programozója. Email posta: . Rabszolga. tel.: 784775. Internet központ.
Oktató:	Kulakov Kirill Alekszandrovics E-mail: . Irodai telefon: 711015. 215-ös szoba
Információ az oktatónak:	13-as csoportszám
Kapcsolódó dokumentumok:	Projekt áttekintése Projektterv Munkaütemezés (Gantt-diagram) Követelmények Specifikáció Tervezés Teszt Megvalósítási Dokumentum Tesztdokumentum Customer Engagement Developer Relations Reports Fejlesztési folyamat Szószedet Felhasználói útmutató

Első találkozás az ügyféllel.

Az első találkozás alkalmával a fejlesztőcsapatot bemutatták az ügyfélnek. A megrendelő pedig a PetrSU tudományos könyvtáráról beszélt.

A könyvtár a „Foliant” automatizált rendszer alapján működik. Az elektronikus katalógus a könyvtári rendszer része. A katalógus keresés lekérdezések segítségével történik. Az operátor keresési karakterláncokat generál, amelyek nagyszámú keresési indexet és keresési kifejezést tartalmazhatnak. Minden kérés rögzítésre kerül egy naplótáblázatban. Ez a táblázat tartalmazza az igénylés időpontjára, a kérelmet benyújtó ügyfél címére, magára a kérésre, a megkeresés eredményére vonatkozó adatokat.

Az ügyfélnek folyamatosan figyelnie kell a naplótáblázatot, és statisztikát kell adnia a keresési indexek használatáról.

Bemutatták a megvalósuló projekt kezdeti követelményeit is. Az egyik követelmény a statisztika hatékony összeállítása. Vagyis a statisztikákat a kérés elküldése után ésszerű idő elteltével kell megjeleníteni. E követelmény miatt a fejlesztők arra ösztönözték a szerveroldali eljárásokat a PL/SQL-ben.

Második találkozás az ügyféllel.

Az ügyfél egy bejelentkezési nevet és jelszót adott a fejlesztőknek az elektronikus katalógusrendszerbe való belépéshez, és két táblázat másolatát biztosította a munkához - egy naplótáblázatot és egy keresési indextáblázatot.

Guryev Dmitry Borisovich részletesebben megismertetett minket az Oracle SQL*Plus DBMS kliensben végzett munkával. A csapat megismerkedett az elektronikus katalógus munkájával.

A "Foliant" rendszer a RusMark szabvány alapján működik, amely körülbelül 99 mezőt tartalmaz. Minden AIBS "Foliant"-tal dolgozó könyvtár kiválasztja a használni kívánt mezőket és almezőket. Vannak speciális GOST-ok, amelyek leírják a könyvtári adatok tárolásának szabályait. Mivel sok mező van, létrehoztuk a keresési indexek rendszerét. Vannak szolgáltatási és nyilvános indexek.

A címtár felhasználókat belső és külső csoportokra osztják. Minden osztálynak vagy alkalmazottnak saját jogai vannak. Az objektumról szóló minden rekord külön elemekre elemezhető, és nem tárolódik egészként.

Harmadik találkozó az ügyféllel.

Az ügyfél egyértelmű követelményeket fogalmazott meg számunkra írásban.

Az ügyfél a következő statisztikák iránt érdeklődik:

1. Az elektronikus katalógus iránti kérelmek száma.

• Az utolsó hónapról napra.
• Havi elszámolás a tárgyévre.
• Évek szerinti elszámolás.
• Készítsen információtörténetet.

Kérelmek listája által mindenkinek keresési index, ahol a keresés eredménye null volt.

A gyakran előforduló kérések listája.

Egy adott időszakra vonatkozó kérések teljesítésének elemzése. A jelentésnek a következő statisztikákat kell tartalmaznia:

• A kérelmek száma.
• A keresési kérelmek száma.
• Az összetett lekérdezések száma.
• A sikeres válaszok száma.
• Null válaszok száma.
Használja a következő keresési indexeket:
• Szerző
• Szerző rev. prod.
• A dokumentum típusa.
• Földrajzi szakasz.
• Adja meg a dátumot.
• Megjelenés dátuma.
• Cím.

Negyedik találkozás az ügyféllel.

Az ügyfél szakembere Guryev D.B. elmagyarázta az SQL*Plus segédprogram telepítésének és konfigurálásának bonyolultságát. A program indítási problémájára a megoldás az SQL * Net csomag telepítése volt, szintén Guryev D.B. megadta a táblázatok pontos nevét a fejlesztők számára, és egy másik táblázatot is hozzáadott a csapat rendelkezésére. A szakember áttanulmányozta az építészeti dokumentumot, és azt javasolta, hogy gyakorlatilag minden típusú architektúrát valósítsanak meg, és válassza ki a legoptimálisabbat. Ugyanakkor kívánatos, hogy ne építsék újra a naplótáblázatot, és amennyire csak lehetséges, egy adott probléma megoldása során általánosítsák a naplótáblázat adatait a különféle helyi statisztikákban való további felhasználás érdekében.

Ügyfél Gorshkova G.A. megismerte a követelménydokumentumot, miután azokat jóváhagyta.

Ötödik találkozó az ügyféllel.

Guryev Dmitrij Borisovicsot, az ügyfél oldali szakemberét felkérték, hogy telepítse az „Oracle” DBMS-sel való munkához szükséges szoftvert a PetrSU képzési szerverére. Vadim Anatoljevics Ponomarjov, aki adminisztratív hozzáféréssel rendelkezik a PetrSU szerverhez, szintén részt vett ebben a folyamatban az egyetem oldaláról.