Milyen a jó specifikáció cms magazin honlapján
Miért lenne a feladatmeghatározás (TOR) a helyszínen?
Bármelyik módszert a fejlődés még nem használt, és nem számít, hogy milyen méretű vagy volt a honlapon, hogy minden esetben, amikor találkoztam a kérdést: „És ha véget ér a munka, akkor rájövünk, hogy már tényleg kész?” A fejlesztés mind. és bármely más weboldal gyakori probléma - senki sem látja végpontot. Egyrészt azt lehet mondani, hogy a végső elképzelés a projekt egy projekt vezetője. De ha a végtermék megfelel, ahogy a menedzser, de nem egyezik az ügyfél elvárásainak? És ha a projekt során megváltozott 3 vezetők?
Következtében Parkinson törvénye „Kilencven-kilencven”:
Az első 90% -a kód vegye fel 90% -a fejlesztési időt. A fennmaradó 10% -át a kódot vegye fel a második 90% -át a fejlesztési időt.
A.Kupera a könyvből: „Mentális kórházi betegek a kezében.”
TK nem csak a követelmények listáját, ezt a dokumentumot. Amennyiben a szerződés szabályozza a szervezeti és pénzügyi kapcsolatok, a TOR szabályozza a fejlesztési folyamat és a végeredmény.
Ebben az esetben nem számít, kicsi vagy nagy honlap fejlesztését. A probléma az eltérés a várakozásokat is előfordulhat, függetlenül az összeget költött, csak a hatása eltérő lehet.
Add korlátozásokat.
Valahányszor beszélni írásban TK, úgy értem, persze, egy lépcsőzetes fejlesztési módszer. Abban az esetben, egyéb opciók (például extrém programozás) és egyéb dokumentumok összeállítása gyakran más elveket. Ez - az időben.
Érdemes megosztás TOR kis és nagy telek. Ez - kettő. Különbségek a kis és nagy projektek nem terjed ki a dokumentum kimenet, valamint a fejlődésük során. Ha csak 4 fő részére a projekt csapat, mind régóta ismerjük egymást, akkor feltételezhetjük, hogy nincs formalizmus. Ha részt veszünk a fejlesztés több „szervek”, és a projekt csapat áll, több mint 10 perc (a végtelenig) személyzet, a kontroll a horda csak folyamatot. A folyamat ad okot, hogy a formális és a formalizmus nyomot hagy a dokumentum formátum.
Tény, hogy a vastagsága a dokumentum összetettségétől függ a folyamat nagyobb mértékben, mint a projekt nagysága.
Követjük a legnehezebb utat.
TK kérdésekre válaszol
TK-t eredetileg a fejlesztés több résztvevő:
- Projektfejlesztőknek (tervezők és programozók).
- Project Manager.
- Ügyfél.
- Bürokraták (nem tudnak részt venni a projektben, de ők is kell számolni).
Visszatekintve az adott csoport résztvevőinek feltételezhető, hogy a TK kell először is, hogy válaszoljon a kérdésekre. Ideális esetben az összes projekt dokumentáció a lépcsőzetes eljárás jön létre, hogy távolítsa el a kérdés a fejlesztési folyamatban.
Szóval, mit kérdésre válaszolt a TK.
Mert valaki, hogy hozzon létre egy telek, és miért?
Amint lesz megoldani a problémát, az ügyfél és a felhasználók?
Hogyan lesz a létrehozása a projekt?
Hogy fogják venni a kimeneten?
TK elkezd fejlődni és véget vet rá.
Ideális esetben meg kell átmenni az összes pontot a TOR az ügyféllel, hogy ellenőrizze a kapott rendszer és egy héttel később azt mondani: „Pfuj. Úgy tűnik, minden kész. "
„TK egy ellenőrzési eszközök a munkát.” - a kifejezést írt bevezetése sok a TK.
Mi szükséges a projekt elindítása tovább?
Ez az a kérdés, hogy jó kell választ kapnia az ügyfél. Ez a tanácsot, de bizonyos esetekben szükséges elvégezni a tervezési folyamatot. Meg kell tervezni a munkahelyek számát szükséges hardver és szoftver stb
Mi TK
Beletelt egy óra, hogy a döntést: leírni az összetétele a TK formájában adott világos szerkezetű, vagy csak beszélni, hogy mi legyen ott. Emlékezés minden a TK, én arra a következtetésre jutott, hogy a szerkezet a dokumentum olyan gyakran változtak függően számos tényezőtől, egyértelműen jelzi, hogy a szerkezet hasonlít egy rossz tanácsot a választott ruha. Képzeld el, hogy tanácsot valamit viselni az esti, sem érdeklődött, hová megy.
általános információk
Az első rész a TOR nyújt bevezetést és általános tájékoztatás a dokumentum és a projekt egészére. A bevezetés kell írni, egyszer és mindenkorra az élet. Általános szabály, hogy vannak írva, így absztrakt kifejezés, hogy minden egyes új projekt csak csípés egy pár szót.
Általános információ a következőket tartalmazza:
Ezt az információt gyűjteni a projekt hatókörét.
A projekt hatóköre
Ha mozog el otthonaikból, és megfordult, hogy ránézzen a távolság nem lesz képes felismerni szerkezetének részleteit. Számíthat az ablakokat, de nem szétszedni, ahonnan azok jelentősek, megcsodálhatja az architektúra ( „élvezni”, persze, nem minden ház), de csak következtetni tudunk elvei építése, akkor nem lehet látni a belső lakások és firkált a szót a bemeneti ajtót.
A projekt hatóköre körülbelül azonos. Ebben a fejezetben az egyik kell elképzelni, hogy akkor érhető el a fejlesztési folyamatban, de ez egyáltalán nem megy bele a részletekbe. Azt írja, hogy a helyszínen fog működni, „felhasználói regisztráció”, de nem írom pontosan hogyan épül, illetve mely területeken kell majd kitölteni egy felhasználó.
A projekt hatóköre van írva formájában felhasználó esetében, a helyszínen, és rendelkezik a funkcionalitás és kölcsönhatás a felületen.
Információs architektúra és interfész
Leírni a hivatal kell leírni a felülről lefelé:
- Oldal struktúráját. Ez az úgynevezett magas szintű prototípusok.
- oldal sablonokat. Alacsony szintű prototípusok, amelyek leírják az interfész a helyszínen is.
- Inventory tartalmat. Táblázatos leírását az egyes oldalak tartalmát.
hely
Sitemap végre grafikusan az egyik a jól ismert jelöléseket: Visio vagy Garrett. Azt javasoljuk, hogy dolgozzon egy helyszínrajz, mert ebben az esetben a kapott szerkezetet kapunk leginkább intuitív és könnyen használható később. Egyrészt úgy tűnhet, hogy egy listát levelet oldaltérkép sokkal könnyebb lesz, de ha nem hagyja abba gondolni közötti kapcsolatok különböző területein a webhely magad, akkor kezdődik, hogy erőszakkal sztrájk élesen négyzetek a papíron.
Ha szeretné megtudni, hogyan lehet felhívni a szerkezet a helyén segítségével jelölés a Visio, írott teljes cikket, miért laknak nem fog. Cikket írt, de angol nyelvű, de könnyen kihasználják őket.
Ne felejtsük el, hogy számmal minden oldalt az oldal térkép. Erre azért van szükség abban a szakaszban a tartalom leírását.
Hasznos tippek, ha felhívják a terület térképét:
- Ne kímélje a teret. Próbálja elhelyezni a blokkokat, hogy azok voltak elválasztva egymástól. Ez segít az olvashatóságot a térkép.
- Nem kisebb. Olvassa el a szöveget egy 4-es méretű, elvileg lehetséges, de ez az oka a gyűlölet.
- Igazítsa a „négyzetek” oldalak egymáshoz képest, az épület a sorban. Ez javítja a megítélése szintek egymásba oldalakon.
- Ne át a vonalat. Próbálja meg elkerülni a nagyszámú alkotott metszéspontját. Ha metszik, akkor kell „ugrik” egymás fölött. Ki volt elfoglalva, a rajz funkcionális áramkörök az egyetemi, értem.
- Bejelentkezés a kártyát. Jelentkezzen maga a kártya, valamint az egyes blokkok. Ez lehetővé teszi, hogy kevésbé zavart a jövőben.
- Gyakran menteni a fájlt. Elcsépelt, de akkor csak azt kell megjegyezni. Nem szükséges újra emlékezni rokonok Visio szoftverfejlesztők, sőt, azok semmilyen módon nem felelős.
Sitemap szoktam tenni a következő részben „alkalmazások”. Általános szabály, hogy az annyira nagy, hogy rátette a közepén a TOR valósággá válik.
elrendezések
Az oldaltérkép minden oldalt számunkra csak egy „szögletes” egy papírlapra. A tervező, kódoló és a programozó nem elég, hogy dolgozzon ki egy website. Még mindig van tudni, hogy a jelenlétét és helyét az információs blokkok és funkciók az oldalon. Ezért folytassa a webhelysablon. Ideális esetben minden doboz kell, hogy legyen részletes áramköre minden egyes oldalt. Ez az oldal prototípus. Használata prototípus függ az elfogadott programok a munka a cégnél-fejlesztő, de el kell ismerni, hogy ez válik rendkívül költséges az ügyfél számára.
Egyszerűsítése osztja számos honlap sablon felület, amelyek leírása a következő oldalon térképet.
Leírás sablon 3 részből áll:
- A sablonok listáját. Azonosítja a főbb oldalak és azok leírásait.
- Modell sablont. Fő blokkok. Leírja az alapvető építőkövei oldalak csökkentése érdekében az előfordulás gyakorisága információkat.
- A leírás az egyes sablon szerint a listán. Minták rajzolunk fel grafikai csomag (Adobe Illustrator, Adobe InDesign, MS Visio et al.), És akkor egészíti ki egy rövid leírást.
Fontos. Oldal felület sablonok nem tévesztendő össze a sablonokat a szoftver rendszer, amely azt a honlapján. Interface sablonok leírására számos standard oldal, elég az oldalak tervezését.
Példa megfordítása TK sablon interfész leírás (vayrfreyma).
Rövid tartalmi
A legtöbb hosszú és unalmas a munka része. Leírása a tartalom tartalmaznia kell egy listát az összes oldalak pontos feltüntetésével forgalomba minden oldalon a szöveg, kép, stb Is, ott jelzi, hogy melyik sablont használnak az oldalon (lásd. Fent). Azt javasoljuk, hogy használja az ebben a táblázatban.
Egy jó leírás a tartalom biztonsági tervezett munka a színpadon a dob helyén, és adja meg adatait.
funkcionális
Leírása a hely funkciót a leírások az egyik kulcsfontosságú szakaszt. Ez különösen érvényes a helyszínek nagy százalékban a program a munka: e-kereskedelem, az online szolgáltatások, stb
Egy jó példa a funkcionális leírást ad a vendégeknek. Azt javaslom, hogy maradjon a leírást a standard funkcionalitást program keretében kifejlesztett honlapján. Meg kell mutatni: a teljes rendszer, a teljes funkcionalitás az alrendszerek és modulok összekapcsolása alrendszerek és modulok együtt, és végül egy lista az összes funkcióját a modulok többé-kevésbé részletes leírása a működésük. Minden modult, akkor kell festeni létrehozott objektumok vagy az alkalmazás által használt.
Lehetőség van arra is, hogy leírja a szerkezetet az adatbázisban, az előzetes munka algoritmusok, hanem a saját szempontjából nem írta elő. GOST ilyen részleteket ismertetni kell a további dokumentumok: elvi és technikai projektek.
Néha, amikor a fejlődő nagy telek kell ülni sokáig, hogy leírja az összes funkcióját a külső és belső részei a helyszínen. Egyes fejlesztők ellen ilyen részletességgel. Úgy vélik, hogy szükséges, hogy leírja a funkcionális felület „az ügyfél egyértelmű volt.” Hülyeség! Tapasztalatból mondhatom, hogy a túlzott részletességgel nem ez a helyzet. Amennyiben probléma merül fel a tervezés a projekt menedzserek mindkét oldalán egyre ritkább fontoskodó! Ezek proofreads TK kívül és belül próbálják bizonyítani az ügyet. Ezért, ha a funkcionalitás a TOR létrehozott közös kliens szavak továbbra is kénytelen csinálni, amit akar.
követelmények
Külön fejezet kell szentelni a követelményeknek a projekt, illetve a projekt a környezetre. Követelményeket, amelyeket leírt feladatmeghatározás az oldalon:
- Rendszer követelmények;
- személyzet követelményeinek;
- Megbízhatósági követelményeknek;
- Követelmények ergonómia és esztétika technikai;
- információvédelmi igényeinek jogosulatlan hozzáférés ellen;
- Követelmények az információk biztonsága baleset esetén;
- A támogatási formák követelményeknek;
- a szoftver követelmények;
- A tájékoztatás követelményeinek;
- hardver követelményeket;
Az is lehet, számos különleges követelmények.
Minden követelménynek egyértelműen fel kell tüntetni, és próbáld meg nem elfelejteni a személyes fejlődése szempontjából a projekt.
Természetesen, a kis projektek nincs szükség regisztrálni az összes fenti követelményeknek. Például a dolgozók egy részét a honlapon nem, így ezek a szakaszok kerülnek átadásra.
A folyamat során a projekt menedzsment, akkor előfordulhat, hogy vannak olyan helyzetek, amelyek túlmutatnak a feladatmeghatározás. Lehet, hogy valami elkerülte, vagy van egy vészhelyzet, amit korábban nem láthatta előre. Mindez segít, hogy fejlessze tovább a dokumentumot, így bele új információkat, amelyeket használni fognak a kommunikáció az ügyfelekkel és a problémák megoldásához.
Mi a következő lépés?
TK készül, aláírt és működésbe lépett. Mi a következő lépés? hogy a munka véget ér vele ezen a ponton? Nem.
A projekt nem mindig megy az előre tervezett módon. Igyekszünk javítani valamit, változtatni, gyakran változó vevői igényeknek. A feladatmeghatározás egy dokumentum, hanem mint a tabletta. A változó követelményeknek a projekt meg kell változtatni, és a feladatmeghatározás. Ezt általában egy listát a kiegészítő iratok változásokat. Természetesen ezek csak abban az esetben, ha az valóban szükséges a gyakorlatban ritkán fordul elő.
Is, akkor fel kell készülnie, hogy a mélyreható vizsgálat az összes résztvevő TK Development a folyamat hibák találhatók a projektben. A hibák száma egy nagy dokumentum egyenesen arányos a mennyiség és fordítottan arányos az időnek írni. mert idő mindig rövid, várható, hogy a hiba a TOR merülnek fel.
az alsó
Írtam ezt a cikket, mint egy évvel ezelőtt. Beletelt egy elég hosszú idő, és én ez idő alatt nem írt egyetlen nagy TK. De, miután elolvasta az információkat, egyetértettem minden, ami írva van. Tehát jó TK webhely tartalmaznia kell:
Remélem, hogy az információ hasznos lesz a szélesebb közönség számára.