Dizajni i Zgjidhjes · Hapi 03 · Si Punojmë
Strategjia dhe Arkitektura përcaktojnë se si duhet të strukturohet një sistem. Dizajni i Zgjidhjes përcakton saktësisht se çfarë ndërtohet — rrjedhat e punës specifike, ndërfaqet, kontratat e të dhënave dhe sjelljet në rast dështimi që kthejnë një drejtim të projektuar në diçka që një ekip mund ta ndërtojë në praktikë.
Kjo fazë nuk fillon me një zbatim. Ajo fillon me një specifikim që është testuar kundrejt provave para se të shkruhet një vijë kodi prodhimi.
Jo kjo pyetje
"Çfarë duhet të ndërtojmë?"
Kjo pyetje, në vend të saj
"A sillet ky dizajn i veçantë vërtet ashtu si e presim, nën kushtet që do të përballet — dhe a mund ta vërtetojmë këtë para se të angazhojmë përpjekje inxhinierike për ta ndërtuar?"
Dizajn · Prototip · Testim · Matje · Specifikim
Pse Dizajni Ndjek Arkitekturën
Arkitektura e referencës nga faza e mëparshme përcakton shtresat, zgjedhjet e teknologjisë dhe çështjet që prekin të gjitha nivelet. Ajo ende nuk përcakton se si duhet të sillet një rrjedhë pune e caktuar kur një kërkesë është e paqartë, ose çfarë ndodh kur një integrim kthen të dhëna të pasakta të formatuara. Dizajni i Zgjidhjes mbyll atë boshllëk — pa të, "arkitektura" mbetet një diagramë, jo një sistem.
Arkitektura e Referencës → Specifikimi i Zgjidhjes
Pse Rigoroziteti i Dizajnit Ka Rëndësi
Hulumtimi i Barry Boehm në ekonominë e inxhinierisë së softuerit — publikuar për herë të parë në 1976 dhe zgjeruar në librin e tij të vitit 1981 Software Engineering Economics — zbuloi që kostoja për të korrigjuar një defekt rritet ndjeshëm sa më vonë të zbulohen.
~1×
Kosto për të rregulluar një defekt të kapur gjatë dizajnit.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Kosto për të rregulluar të njëjtin defekt pas publikimit në prodhim, në varësi të shkallës së projektit.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
Kjo gjetje është rishqyrtuar që atëherë. Rishikimi i vetë Boehm dhe Basili në 2001 vuri re se kurba është në masë të konsiderueshme më e sheshtë për ekipe më të vogla, që iterojnë shpejt dhe kanë testim të fortë dhe dërgesë të vazhdueshme. Multiplikatori nuk është universal, dhe ne nuk e trajtojmë si të tillë.
Por drejtimi i gjetjes nuk është rrëzuar: kapja e një defekti në dizajn para se të ndërtohet është më e lirë se kapja e tij më pas. Kjo është arsyeja pse OpenQCore trajton prototipimin dhe testimin si pjesë të vetë dizajnit — jo si një fazë që ndodh pasi ndërtimi ka nisur.
Nga Arkitektura te Specifikimi
Çdo vendim arkitektural nga faza e mëparshme dekompozohet në specifika konkrete.
Renditja e saktë e hapave, pikave të vendimmarrjes, përjashtimeve dhe dorëzimeve që një zgjidhje duhet të mbështesë — e bazuar në Modelin e Rrjedhës së Punës në Gjendjen Aktualë të prodhuar gjatë zbulimit, jo në një proces të rizbuluar ideal.
Ajo që çdo përdorues, sistem ose agjent në të vërtetë sheh, dërgon dhe merr — ekranet, rrjedhat bisedore, kontratat e API-së, dhe fushat që kanë rëndësi në çdo hap.
Forma e saktë, rregullat e validimit, qasja e versionimit dhe pronësia e të dhënave që lëvizin midis komponentëve.
Çfarë bën sistemi — dhe qartë çfarë nuk bën — në kushte normale, raste kufitare dhe kushte dështimi.
Dalje
Specifikimi i Zgjidhjes (Projekt)
Dizajni i Rrjedhës së Punës & Interaksionit
Një ndërfaqe bisedore e vendosur mbi një rrjedhë pune të thyer nuk e zgjidh rrjedhën e punës — e fsheh atë, derisa kufizimi themelor të shfaqet përsëri diku tjetër.
Dizajni i Zgjidhjes nis nga provat e rrjedhës së punës të mbledhura gjatë zbulimit, dhe parashtron një pyetje strukturore para se të bëhet pyetja e ndërfaqes: cilat hapa në këtë proces duhet të automatizohen, cilët duhet të mbeten njerëzorë, dhe ku saktësisht transferohet përgjegjësia midis tyre? Ne e hartojmë këtë në mënyrë eksplicite, në mënyrë që pikat e ndërhyrjes njerëzore të jenë një vendim dizajni i qëllimshëm — jo një aksident i asaj që teknologjia ka qenë në gjendje të bëjë.
Pika kontrolli të qarta ku rishikimi, vlerësimi ose autorizimi njerëzor kërkohet nga dizajni — jo nga mosveprimi.
Kufizime të përcaktuara saktësisht mbi atë që një sistem lejohet të vendosë ose kryejë pa miratim njerëzor.
Rrugë të dizajnuara për rastet që bien jashtë trajtimit normal — jo dështime të heshtura ose zgjidhje rezervë të paracaktuara.
Prototipim & Eksperimentim
OpenQCore trajton dizajnin në fazat e hershme ashtu si shkenca e dizajnit trajton një artefakt të sistemeve të informacionit: si diçka të ndërtuar posaçërisht që mund të vlerësohet kundrejt një problemi të vërtetë, jo thjesht të admiruar për elegancën e tij. Kjo qasje — e formalizuar në punën me ndikim të Hevner et al., 'Design Science in Information Systems Research' (MIS Quarterly, 2004) — trajton artefaktin dhe vlerësimin e tij si të pandashëm. Ne zbatojmë të njëjtin arsyetim të bazuar në hipoteza që përdoret gjatë fazës së zbulimit, në nivelin e dizajnit.
Një vendim dizajni specifik dhe i falsifikueshëm — jo një drejtim i paqartë.
Një përfaqësim punues i mjaftueshëm për të testuar vendimin — jo domosdoshmërisht i gatshëm për prodhim.
Të dhëna hyrëse reale ose realisht përfaqësuese, jo shembuj të idealizuar të zgjedhur për të pasur sukses.
Krahasim kundër bazës referuese dhe kritereve të suksesit të vendosura gjatë zbulimit — jo një përshtypje subjektive e cilësisë.
Dizajni mbahet, modifikohet ose braktiset bazuar në atë që tregoi testi — jo në bazë të sasisë së punës që është bërë tashmë.
Qëllimi i një prototipi nuk është të demonstrojë se një dizajn mund të funksionojë. Është të përcaktojë nëse ai funksionon në mënyrë të besueshme, nën kushtet që sistemi i përfunduar do të përballet në të vërtetë.
Specifikimi i të Dhënave & i Ndërfaqes
Dështimet e integrimit rrallë burojnë nga një vendim i vetëm qartësisht i gabuar. Ato priren të vijnë nga paqartësia — një fushë që u supozua të ishte gjithmonë e pranishme, një rast gabimi që askush nuk e shkroi, një mos-përputhje versioni që askush nuk e planifikoi.
Kjo është punë që me qëllim nuk është glamuroze. Ajo është gjithashtu puna që përcakton nëse një sistem që performon mirë në një demo vazhdon të performojë mirë në prodhim, pas gjashtë integrimeve dhe tetëmbëdhjetë muajve.
Dizajnim për Dështimin, Jo Vetëm Për Suksesin
Shumica e dështimeve të dizajnit nuk janë dështime të rrugës së suksesshme. Ato janë dështime të asaj që ndodh kur diçka shkon keq — një sistem i sipërm jep timeout, një dokument nuk nxirret pastër, një model është i pasigurt, një përdorues bën diçka të papritur. OpenQCore këto kushte i harton qëllimisht në vend që t'i zbulonte në prodhim.
Çfarë bën sistemi kur besimi në një rezultant është i ulët — duke përfshirë nëse dhe si e shpreh këtë.
Çfarë funksionesh mbeten në dispozicion kur një varësi dështon, në vend të një ndërprerjeje të plotë të sistemit.
Kushtet specifike nën të cilat një rast i dorëzohet një njeriu dhe çfarë konteksti përfshin ai dorëzim.
Si sillet sistemi ndaj të dhënave hyrëse të keqformuara, sekuencave të papritura, ose tentativa për keqpërdorim — jo vetëm ndaj kërkesave të mirëformuara.
Një sistem që kurrë nuk është pyetur "çfarë ndodh kur kjo dështon?" nuk është në të vërtetë projektuar. Ai vetëm është demonstruar.
Kriteret e Validimit të Përcaktuara Para Ndërtimit
Në përputhje me parimin e vendosur gjatë zbulesës — se suksesi duhet të përcaktohet para zbatimit — Dizajni i Zgjidhjes prodhon kritere pranimi të shprehura dhe të shkruara dhe një plan testi para se të fillojë zhvillimi në prodhim.
Çfarë duhet të bëjë në mënyrë të saktë zgjidhja, të shprehur në terma të testueshëm.
Në përputhje me karakteristikat e njohura të cilësisë së softuerit — duke përfshirë efikasitetin e performancës, besueshmërinë, përdorshmërinë, sigurinë dhe mirëmbajtjen, të organizuara sipas modelit të cilësisë së produktit softuerik ISO/IEC 25010 — të përcaktuara si objektiva të matshme dhe jo si aspirata të përgjithshme.
Skenarët specifikë, grupet e të dhënave dhe kushtet kundër të cilave zgjidhja do të vlerësohet para se të konsiderohet gati për ndërtim në formë prodhimi.
Porta e Rishikimit të Dizajnit
Kjo praktikë ka precedent: metoda formale e inspektimit të dizajnit dhe kodit e Michael Fagan, e prezantuar në IBM në 1976, vendosi se rishikimi i strukturuar, i bazuar në kritere, kap defektet më herët dhe në mënyrë më të besueshme se aprovimi informal. OpenQCore aplikon të njëjtin parim në dizajnin e zgjidhjes.
Specifikimi është mjaft i saktë, prototipi përmbushi kriteret e vlerësimit dhe zhvillimi mund të fillojë.
Drejtimi themelor është i saktë, por elementë të caktuar duhet rishikuar bazuar në atë që zbuloi testimi.
Puna e dizajnit zbuloi një kufizim që arkitektura nuk e kishte llogaritur — përgjigjja e duhur është të rishikohet struktura, jo të projektosh për ta anashkaluar atë.
Puna e dizajnit zbuloi një rrezik — teknik, operacional, i sigurisë ose etik — që kërkon një vendim mbi autoritetin e ekipit të dizajnit para se të vazhdohet.
Një portë e dizajnit që gjithmonë thotë 'po' nuk është portë.
Çfarë prodhon Dizajni i Zgjidhjes
Në varësi të shkallës së angazhimit, kjo fazë prodhon:
Flukset e punës, ndërfaqet, kontratat e të dhënave dhe sjellja, me detaje të mjaftueshme për t'u ndërtuar pa nevojën për të ripërcaktuar qëllimin.
Përfaqësime vizuale të rrjedhës së procesit, duke përfshirë pikat e qarta ku njeriu përfshihet në proces.
Skeemat, rregullat e verifikimit dhe strategjia e versionimit për çdo ndërfaqe midis komponentëve.
Çfarë u testua, kundrejt cilës baze krahasuese, dhe çfarë mbështesin ose përjashtojnë rezultatet.
Kushtet e dështimit të dokumentuara dhe përgjigja e projektuar e sistemit për secilën.
Kushtet specifike dhe të matshme që zgjidhja e ndërtuar duhet t'i plotësojë para vendosjes.
Nga Dizajni në Zhvillim & Integrim
Dizajni i Zgjidhjes prodhon një specifikim të testuar dhe të verifikuar — jo një sistem të përfunduar. Faza e ardhshme e kthen atë specifikim në softuer funksional, i integruar me sistemet me të cilat duhet të punojë.
Specifikimi i Zgjidhjes → Vlerësimi i Prototipit → Kriteret e Pranimit → Zhvillimi & Integrimi
Hapi 04
Ndërtoni zgjidhjen e specifikuar sipas kritereve të pranimit të përcaktuara — jo sipas supozimeve.
Referencat Kërkimore & Metodologjike
Boehm, B. — Ekonomika e Inxhinierisë së Softuerit (1981); Boehm, B. & Basili, V. — "Lista Top 10 për Reduktimin e Defekteve të Softuerit," IEEE Computer (2001)
Burimi i gjetjeve mbi koston e ndryshimit të përmendura më sipër, përfshirë rishikimin e mëvonshëm që tregon një kurbë më të sheshtë për ekipet më të vogla që iterojnë shpejt.
Hevner, A., March, S., Park, J., & Ram, S. — "Shkenca e Dizajnit në Kërkimin e Sistemeve të Informacionit," MIS Quarterly (2004)
Kornizë themelore për trajtimin e një artefakti të një sistemi informacioni dhe vlerësimin e tij si të pandashëm — baza për ciklin prototip-test-rafino të përshkruar më sipër.
Fagan, M. — "Inspektimet e Dizajnit dhe Kodit për të Zvogëluar Gabimet në Zhvillimin e Programit," IBM Systems Journal (1976)
Origjina e rishikimit të dizajnit të strukturuar, të bazuar në kritere, si një praktikë formale inxhinierike, e përmendur në Porta e Rishikimit të Dizajnit më sipër.
ISO/IEC 25010:2011 — Kërkesat dhe Vlerësimi i Cilësisë së Sistemeve dhe Softuerit (SQuaRE) — Modelet e Cilësisë së Sistemit dhe Softuerit
Burimi i karakteristikave jo-funksionale të cilësisë të përmendura në kriteret e pranimit më sipër.
