Enginyeria de Requisits: Tècniques, Gestió i Proves
Enviado por Chuletator online y clasificado en Otras materias
Escrito el en 
catalán con un tamaño de 1,56 MB
Tècniques de Validació de Requisits
Hi ha diverses tècniques per a la validació de requisits, dividides en famílies:
- Tècniques de revisió:
- Inspecció
- Walkthrough
- Comentari
- Tècniques basades en la generació d'artefactes:
- Verbalització de models
- Creació d'escenaris
- Creació de casos de test
- Creació de manuals
- Validació basada en prototips
Preparació de l'Activitat de Validació
Independentment de la tècnica, primer cal:
- Definir l'objectiu de la validació.
- Identificar els participants requerits, depenent de l'objectiu.
- Seleccionar el lloc on fer la validació, amb l'equip necessari.
- Convidar amb suficient antelació i informar els participants.
- Depenent de la tècnica, decidir els rols.
TR1: Inspecció
Es detecten defectes en els requisits a partir de seguir de manera estricta un procés ben definit.
Rols:
- Organitzador
- Moderador
- Lector
- Autor
- Inspector
- Anotador
Procés:
- Inici de la sessió, l'autor explica als inspectors els artefactes a revisar.
- A la fase de detecció, els inspectors detecten errors potencials.
- Generalment treballen individualment.
- Fan servir pautes per a la detecció de defectes.
- A la fase de recol·lecció es discuteixen els defectes trobats.
- Si un defecte no es confirma, no s'incorpora a la llista de defectes.
- Per documentar els defectes trobats, s'utilitza un formulari especialment dissenyat.
TR2: Walkthrough
Inspecció lleugera. El procés de validació no està estrictament pautat ni la diferenciació de rols està afinada.
- Hi ha autor i inspector.
- L'autor presenta l'artefacte i remarca els punts en què vol que es centrin.
- Els inspectors comenten els errors trobats i donen suggeriments, l'autor anota per fer correccions posteriorment.
TR3: Comentari
Forma informal de validar requisits puntualment. L'autor dóna el document a una altra persona per recollir la seva opinió respecte a la qualitat dels requisits.
Els defectes s'apunten al mateix document amb una breu explicació del problema.
Tècniques de Suport
TS1: Lectura Basada en la Perspectiva
Adequada per a les tècniques de revisió i, implícitament, en la validació basada en la generació d'artefactes.
El revisor busca defectes adoptant una perspectiva determinada, com si fos un client o un tester. Per cada perspectiva a considerar, cal preparar instruccions que s'han de donar a l'inspector.
Es pot proporcionar una llista de preguntes extres que l'inspector ha de respondre a partir de:
- El contingut dels requisits.
- Què ha comprès dels requisits.
TS2: Checklist
Útil quan s'han de considerar molts aspectes. Ha de tenir preguntes molt precises orientades a detectar errors i que guiïn l'auditor en aquest procés.
- Fomenta que la validació es faci de manera estructurada.
- Com que cada auditor valida els requisits de la mateixa manera, facilita la comparació dels resultats per cada un.
Cal evitar llistes de verificació llargues, ja que dificulten el seu ús.
- Recomanable no més d'una pàgina.
- Si l'auditor pot memoritzar-la, evitar consultar-la tota l'estona.
Validació Basada en la Generació d'Artefactes
La idea és usar els requisits a validar com a referència per crear parcialment altres artefactes a desenvolupar.
Els artefactes que es generen tenen l'únic propòsit d'assistir en la detecció d'errors.
- Els criteris de qualitat per als artefactes es poden obviar.
- Com que els artefactes generats no s'aprofitaran, cal reduir l'esforç per generar-los.
Ajuden a la validació perquè:
- Durant el procés de creació de l'artefacte, es veuen errors en els requisits.
- Els artefactes creats fan accessibles els requisits en què es basen a altres stakeholders.
GA1: Verbalització de Models
Transformació d'un requisit formal a llenguatge natural.
Facilita la validació dels requisits a stakeholders que no estan familiaritzats amb el format de la documentació inicial. Sovint es fa com a activitat prèvia a una inspecció o walkthrough.
En la transformació cal ser curós, no afegir, canviar ni eliminar informació expressada en el model original. Per tant, és recomanable que la verbalització no la faci l'autor del model original.
Els problemes detectats en la verbalització es documenten.
GA2: Creació d'Escenaris
Usat principalment per validar requisits des de la perspectiva d'ús del sistema.
- Es valida si a partir dels requisits documentats es pot derivar com s'usa el sistema, i si aquesta manera és la desitjada pels stakeholders.
Els creadors d'escenaris usen plantilles estàndard per especificar-los i regles definides de com generar-los.
Igual que en GA1, l'escenari permet que els stakeholders sense coneixement tècnic puguin validar els requisits.
GA3: Creació de Casos de Test
Els inspectors formen part de les activitats relacionades amb el test del sistema per validar els seus requisits. Els casos de test generats tenen l'única finalitat de detectar errors en els requisits, per tant, no cal que siguin complets ni que compleixin els criteris de qualitat.
S'usen plantilles per a la generació dels casos de test, així com instruccions a seguir per crear-los a partir dels requisits.
Per generar casos de test, cal partir de requisits detallats i que hagin estat validats amb altres tècniques.
GA4: Creació de Manuals
En general, els manuals d'usuari no s'escriuen fins que el procés de desenvolupament d'un sistema ha finalitzat.
No obstant això, si s'anticipa la creació del manual, ajuda a validar els requisits del sistema.
- Tenir un manual d'usuari preliminar permet validar anticipadament el sistema des del punt de vista de l'usuari final.
Per generar el manual, cal partir d'una estructura acordada amb els stakeholders rellevants.
- Definir una plantilla, anotar instruccions per a la seva redacció.
El manual ha de contenir:
- Esquemes de resum fàcils de comprendre.
- Explicar què fa el sistema en cas de problema.
- Mostrar gràficament quina seria la interfície de l'aplicació.
Validació Basada en Prototips
Molts defectes són difícils de detectar analitzant descripcions en llenguatge natural o models gràfics.
L'experiència mostra que molts defectes no es detecten fins que els stakeholders experimenten el sistema final. Detectar aquests errors és massa tard, ja que reparar-los té un cost molt gran.
Amb un prototip podem anticipar aquesta experimentació dels stakeholders amb el sistema.
La creació del prototip ja portarà a la detecció de defectes, és un cas més de validació basada en la generació d'artefactes.
Creació de Prototips
A diferència del prototip d'elicitació, el prototip de validació intenta ser el més real possible. A causa de les limitacions en recursos, haurem de ser selectius respecte als requisits funcionals i de qualitat que considerem per fer la validació.
Ús dels Prototips
Per detectar defectes mitjançant l'ús del prototip, no n'hi ha prou amb donar el prototip als inspectors. Se'ls ha de donar informació de quins aspectes del sistema interessa validar.
- Reduïm el risc que experimentin parts que no ens interessen.
Com que les necessitats d'un usuari nou i d'un usuari experimentat són diferents, interessen aquests dos punts de vista.
- Caldrà preparar material per poder generar un usuari experimentat.
A banda dels defectes que documentin, podem recollir informació a partir d'observar com l'usen.
Gestió de l'Enginyeria de Requisits
Implica atendre tres objectius:
- Gestió del context del sistema: Observar el context, detectar canvis rellevants i suggerir activitats apropiades per ajustar el procés d'Enginyeria de Requisits i els artefactes, acomodant-los als canvis del context.
- Gestió del procés d'Enginyeria de Software: Definir quina activitat de l'Enginyeria de Requisits executar a cada moment.
- Gestió dels artefactes de requisits: Donat el gran nombre d'artefactes creats durant l'Enginyeria de Requisits i la seva contínua evolució, gestionar-los és una tasca complexa.
- Establir la traçabilitat.
- Prioritzar la seva generació o ús.
- Gestionar els canvis que s'hi facin.
Gestió del Context
L'objectiu és identificar canvis en el context, anticipar-los i estimar-ne l'impacte.
Canvis de l'entorn que impacten en el projecte de software:
- Aparició d'una nova tecnologia.
- Aparició d'un competidor.
- Canvis en la llei.
- Evolució dels objectius dels stakeholders.
- Necessitat d'involucrar stakeholders addicionals.
- Canvi en la manera com els actors externs usaran el sistema.
L'observació del context es realitza també amb el gestor de projecte i de producte, per tant, cal coordinar-se amb ells:
- Gestor de projecte: Identifica riscos en connexió amb canvis de context.
- Gestor de producte: Controla els sistemes competidors en el mercat.
Tècniques:
- Escaneig del context: Cerca canvis a l'entorn del sistema. Es fa periòdicament o bé després d'un esdeveniment determinat.
- Monitorització del context: Registre continu de l'evolució del context. Realitzada pels comercials d'una empresa.
- Prognosi del context: A partir dels resultats generats en la monitorització o l'escaneig, especificar canvis factibles en el context en el futur.
Gestió del Procés
L'objectiu és monitoritzar, controlar i ajustar la planificació de les activitats d'elicitació, documentació, gestió de conflictes i validació, aplicant tècniques de la gestió de projectes.
No es pot fixar una seqüència d'activitats a seguir que assoleixi els objectius de l'Enginyeria de Requisits:
- Conèixer i comprendre en el nivell de detall requerit tots els requisits rellevants.
- Obtenir un acord respecte als requisits entre tots els stakeholders involucrats.
- Documentar tots els requisits acordats amb els formats i regles considerats.
Aproximació Basada en Fases
Les activitats d'Enginyeria de Requisits s'executen seguint un model de procés de quatre fases seqüenciades en què s'estableixen diferents cicles de realimentació.
L'ordre ve definit, bàsicament podem definir el temps a dedicar a cada activitat.
Aproximació Depenent de la Situació
L'objectiu és determinar en cada moment quina activitat és més productiva.
- Pretén evitar fer tasques que aportin poc al progrés real.
- Exemple: Si la comprensió és pobra i no hi ha acord entre els stakeholders, l'esforç dedicat és inútil.
Facilita una planificació flexible i afinada. Es consideren els artefactes de manera individual, la validació es fa quan es creu necessària.
Aquesta aproximació és especialment adequada per desenvolupar sistemes on hi haurà canvis freqüents.
- Quan els stakeholders no estan familiaritzats amb el sistema o el context.
- Quan s'han de desenvolupar requisits innovadors.
Procés
Donat un artefacte, primer s'avaluen tres dimensions de l'Enginyeria de Requisits: contingut, acord i documentació. Els stakeholders implicats avaluen de manera conjunta:
- +: Sense deficiències.
- 0: Deficiències menors.
- -: Deficiències majors.
Si és +++, es fa la validació. Si no, - > 0 > +. En cas d'empat: Elicitació > Documentació > Gestió de Conflictes.
Regles de Selecció d'Activitat
- Si un artefacte no té cap deficiència òbvia en les tres dimensions, es fa la validació.
- Una deficiència major té més prioritat que una deficiència menor en una altra dimensió.
- Una deficiència menor en una dimensió té més prioritat que cap deficiència en una altra dimensió.
- En cas de la mateixa avaluació en diverses dimensions, la dimensió de contingut té més prioritat que la de documentació, i la de documentació té més prioritat que la d'acord.
- Elicitar contingut addicional implica activitats de documentació i negociació.
Gestió d'Artefactes: Traçabilitat
Tasques:
- Definir quins atributs mantenir per a cada tipus d'artefacte. S'ha de mantenir tota la informació rellevant, però al mateix temps, evitar dedicar recursos a omplir atributs innecessaris.
- Gestionar la traçabilitat dels artefactes de requisits.
- Prioritzar els requisits. Assegurar que els recursos disponibles es dediquin a processar els requisits més rellevants, segons el criteri fixat.
- Gestionar els canvis en els requisits.
- Gestionar la configuració dels requisits.
Atributs dels Requisits
A part de la informació que mostra el document d'especificació, hi ha altres coses a mantenir al llarg del projecte:
- Font, tipus, prioritat, estatus de la documentació, etc.
La tendència és gestionar els requisits en una base de dades i extreure l'especificació del requisit com a vista concreta de la informació de la base de dades.
Traçabilitat dels Requisits
Donat un requisit, l'objectiu és poder seguir:
- Cap al seu origen.
- Cap a la seva realització.
- Cap als artefactes que el validen.
Pros
Donar suport a diverses activitats del desenvolupament d'un sistema:
- Verificar si un requisit ha estat implementat en el sistema.
- Detectar funcions i qualitats del sistema innecessàries.
- Verificar si contribueixen a la implementació d'un requisit del sistema.
- Analitzar l'impacte d'una petició de canvi en el sistema: identificar quins artefactes s'han de modificar, estimar l'esforç requerit.
- Mantenir més fàcilment el sistema: permet identificar què es troba afectat per un error en una part del sistema.
- Reutilitzar artefactes entre projectes: si els requisits d'un nou sistema es corresponen amb els requisits d'un sistema previ, es poden identificar artefactes de desenvolupament que es poden reutilitzar o adaptar al nou sistema.
Traçabilitat Específica d'un Projecte
Registrar tota la informació de traçabilitat que potencialment pot ser d'ús en el desenvolupament posterior requereix molts recursos i és impossible a la pràctica.
Per a cada projecte, cal decidir quina informació de traçabilitat s'ha de registrar i mantenir, considerant:
- Quin és l'ús que se'n vol fer.
- Quins recursos es disposaran per gestionar la traçabilitat.
Cal, doncs, definir:
- Model de traçabilitat.
- Estratègia de registre.
- Estratègia d'ús.
Documentació i Visualització de la Traçabilitat
Per documentar els lligams entre artefactes, s'usen:
- Referències textuals.
- Hiperlinks.
Per visualitzar la informació de traçabilitat, s'usen:
- Matrius de traçabilitat.
- Grafs de traçabilitat.
Gestió d'Artefactes: Priorització
A causa de les limitacions en recursos, normalment no es poden considerar tots els requisits en el desenvolupament d'un sistema.
L'objectiu de la priorització és assegurar que els recursos limitats s'usen de manera que s'assoleixi el major nombre de requisits importants possible i de la manera més completa possible.
La prioritat d'un requisit documenta la importància del requisit respecte a un o diversos criteris de priorització.
La priorització ha d'estar sempre dirigida per un objectiu clar.
Priorització dins l'Enginyeria de Requisits
La priorització de requisits també té sentit per a cadascuna de les cinc activitats de l'Enginyeria de Requisits.
- Elicitació: Quins requisits escollir prioritàriament.
- Documentació: Prioritzar els requisits per saber l'ordre en què s'han de documentar.
- Gestió de conflictes: Prioritzar els conflictes respecte a la seva influència en l'èxit del projecte.
- Validació: Determinar quins requisits es validen, prioritzar quins defectes es resolen.
- Gestió: Prioritzar les peticions de canvi, determinant quines es processen primer.
Preparació de la Priorització
- Definir els criteris de priorització.
- Determinar els stakeholders a involucrar. Com a mínim, n'hi ha d'haver un de:
- Equip de desenvolupament.
- Gestió del projecte.
- Clients/usuaris.
- Testers.
- Seleccionar els artefactes a prioritzar. És important prioritzar artefactes al mateix nivell d'abstracció. Es tendeix a donar més prioritat a requisits de nivell d'abstracció superior.
- Seleccionar la tècnica de priorització adequada.
Tècniques de Priorització
En la majoria de projectes, n'hi ha prou amb aplicar tècniques senzilles.
- Les tècniques més sofisticades es recomanen quan el risc de fracàs per una mala priorització és molt alt.
- Bàsicament, el problema de les tècniques sofisticades és que requereixen més recursos.
Tipus de tècniques segons:
- Basades en ordenació o classificació.
- Apliquen un únic criteri o múltiples criteris.
Priorització Basada en Classificació amb un Criteri
Seleccionat un criteri, els stakeholders han de definir:
- Un conjunt de classes per a aquest criteri.
- Les característiques que un requisit ha de tenir per ser assignat a una de les classes.
Els requisits es classifiquen en tres classes, segons l'efecte de la satisfacció del client:
- Delighters: Requisits atractius.
- Satisfiers: Peticions explícites.
- Dissatisfiers: Requisits obligatoris però no explícits.
En el procés d'assignar requisits a una classe, es descarten els requisits innecessaris.
Esquema de Classificació Kano
- Identificar el conjunt de característiques del sistema a classificar.
- Crear un qüestionari dual per a cada característica, per conèixer com se sent l'usuari si el sistema inclou o exclou la característica.
- Analitzar les respostes dels qüestionaris donades pels usuaris i calcular la resposta mitjana.
- En funció de la resposta mitjana, assignar una classe a cada característica.
Anàlisi de la Classificació Kano
- Si considerem must-be, neutral i live with com a resposta neutral, la classificació donada a una característica és més fàcil d'entendre.
Priorització Basada en Classificació amb Dos o Més Criteris
- Un esquema basat en un criteri es pot estendre a N criteris.
- Cal definir com seran els requisits assignats a cada classe, i el nombre creixent de classes fa que sigui complex i requereixi molt de temps prendre la decisió.
Priorització Basada en Ordenació amb un Criteri
- Ad-hoc ranking: Els requisits s'ordenen respecte al criteri triat.
- D'una llista ordenada, posteriorment es pot mirar només un nombre prefixat (top-ten technique).
- Si la quantificació no és òbvia, es pot usar el mètode de comparació per parells.
Mètode de Comparació per Parells Bàsic
- Establir el criteri de comparació.
- Per valorar N requisits, fer una matriu N*N.
- Per a cada parella de requisits (i,j), estimar quin és millor.
- A partir de la matriu omplerta, sumar el valor de cada fila.
- El valor obtingut determina la prioritat de cada requisit.
Fer n*(N-1)/2 comparacions.
Mètode de Comparació per Parells Matisat
- Establir el criteri de comparació.
- Matriu N*N.
- Per a cada parella (i,j), avaluar el criteri:
- Els requisits tenen la mateixa valoració.
- El requisit i té un valor lleugerament superior a j.
- El requisit i té una valoració extremadament superior a j.
- Si a la cel·la (i,j) hem assignat un valor V, la cel·la (j,i) serà 1/V.
- A partir de la matriu omplerta, calcular la valoració de cada requisit, calculant el vector propi de la matriu, operant perquè els elements siguin 1.
Tècniques d'Ordenació Basades en Múltiples Criteris
- Sovint es refereix com a processos analítics de priorització.
- Veurem dues tècniques: matriu de priorització de Wieger, aproximació valor-cost.
Matriu de Priorització de Wieger
- Exemple de procés analític de priorització.
- Considera quatre criteris: benefici, penalització, cost i risc.
- Es basa en l'assumpció que la prioritat és:
- Proporcional a: benefici que aporta i penalització que implica.
- Inversament proporcional a: cost i risc associat.
Procés:
- Determinar el pes de cadascun dels quatre criteris (0-1).
- Llistar els requisits a ser prioritzats en una matriu.
- Estimar el benefici relatiu de cada requisit (1-9).
- Estimar la penalització de no implementar cada requisit (1-9).
- Calcular el valor de cada requisit: valor = Benefici * pesBenefici + Penalització * pesPenalització i després el valor proporcional (valor%).
- Estimar el cost relatiu de fer cada requisit (1-9).
- Estimar el risc de cada requisit (1-9).
- Calcular la prioritat del requisit: prioritat = valor% / (cost% * pesCost + Risc% * pesRisc).
- Ordenar.
Aproximació Valor-Cost
- Basat en una tècnica de suport a la presa de decisions, Analytic Hierarchy Process (AHP).
- És un procés analític basat en:
- L'enginyer revisa els requisits a prioritzar, assegurant que estiguin completa i clarament especificats.
- El client determina el valor relatiu amb parells matisats.
- Els enginyers de software valoren el cost usant parells matisats.
- Es calcula el cost i el valor percentual de cada requisit i es crea un diagrama cost-valor.
- S'usa el diagrama per establir la prioritat.
Priorització Combinada
- Quan hi ha un gran nombre de requisits, cal combinar diferents tècniques.
- És popular el garbellat de requisits.
Procés:
- Primer es classifiquen els requisits ad-hoc en tres classes (classe I: obligatoris en la propera release, classe II: no obligatoris, classe III: si sobren recursos).
- Es tracten tots els requisits de la classe I.
- Si queden recursos, es fan els de la classe III usant un mètode analític.
Gestió del Canvi
- Analitza les peticions de canvi, decideix si dur-les a terme i controla que es facin adequadament, però no implementa els canvis.
- Realitzar un canvi en els requisits implica que aquest evoluciona. La informació d'aquesta evolució s'ha de guardar i mantenir-la fa una bona gestió de la configuració.
Versions, Configuracions i Baselines (Releases)
· versio -> estat artefacte · configuracio: conjunt vers. d'artefactes relacionats · release: config estable de vers. d'artefactes
gestio sistematica del canvi
· a principi fases no cal seguir gestio canvi
· Per realizar canvi a release, es imprescindible Gest. sis del canvi
·tipus peticions: add req, delete req, extendre req, redui req, canviar req
·ha de constituir junta de control del canvi que: analiza cada peticio i clasifica com canvi (correctiu/adaptiu/exepcional), estima esforç canvi, avalua peticio i pren decisio, prioritza petis aceptades.
Junta control canvis
· equip petits, same person dif rols · cas extrem, 1 de clients, 1 de equip · definir clarament kii decide sobre peticion canvi(change manager)
Tasques Change Manager
· cas conflicte, asisteix negociacio
· documenta decisions
·comunica decisions asociades a SH corresponents
· monitora integracio canvi, informa proges a junta
· pot delegar rol a altre membre
TEST BASAT REQS
prova de SW
·obj executar sys o parts en entorn controlat per detectar desviacions, comprobar compleix criteri aceptacio definit
· NO pot garantir correctesa program
· requereix : definir casos prova i executar la prova
Pros tractar aviar la prova
·Sinergia entre prova SW i EngReqs
· Benefici definicio cas prova per detectar defectes a especificacio
Activitats prova SW
Test cases
Especifica info requerida per execucio prova.
Tipus Proves
Caixa negra
·obj verificar comportament sys o part es desitjat
· no importa logica interna
· construeixen partir espefiiciacio dels reqs per funcs incorrectes/absents, qualitats dels reqs no satisfetes, errors d'UX, errors en l’accés a BD externes, errors d’inicialització / finalització.
derivacio test cases valors limits
Errors tienden a pasar en fronteres, cada particio diña dif cas prova prenent valors prop dels limits
proves caixa blanca
·Obj definir cas prova x testejar la codificacio modul
· analitzant codi, selecionar dif camins execucio
· camins execucio determinen partir criteri de cobertura establert
· permet examinar part sys que rarament usa
Proves caixa gris
·Obj verificar comportament sistema o part es el desitjat
· la dif es que trey profit de saber estructura dades i algoritmes per fer els test cases i fer prova mes efectiva y inteligent
Nivel de Proves
Model en V de Boehm
Test cases poden basar en codi o especificacions
implica aplicabilitat a nivells i cobertura de la implementacio
Prova usant Especificació
Definicio test case basat reqs
·partir treball fet a EngReqs pot anticipar prova sys basat especificacio (Caja N)
·test cases relacionats con propietats del sys IMP per client i user
·exec de test permet detectar reqs k falta o implementaicon mal
· proposat 2 aprox per derivar test cases: 1. directa 2. basat models
Escenaris casos prova
·Molts casos exec test compren seq interaccions entre elems de context obj de prova i propi objecte
·escenaris test case: especifica interacion a dif nvl abstraccio
Nivells de les proves i tipus escenaris
Escenaris de context: tenir compte interaccion de context k poden afectar sys
Derivacio directa testcase
Req funcional -> escenaris -> test case -> conjunt proves -> script proves
Derivacio testcase basat models
·Quan reqs especificat amb eines modelat, poden usar com models prova
·cada cami representa un escenari de prova
·es defineixen els camins segons covertura
Derivacio testcxase partir de models
Cas us i escenaris -> model comportament -> escenaris de cas prova basat en model-> determinar cas prova
pro: · sistematiza generacio escenarsi cas prova i per tant generacio cas prova · models usats i camins generats permeten veure què provoquen i què no