Guia d'Enginyeria del Programari i Metodologies Àgils

Complexitat Ciclomàtica i Requisits

Complexitat ciclomàtica:

• Forma 1: nombre de regions + externa = 5 + 1 = 6.
• Forma 2: nodes condició + 1 = while + case 5 + case 6 + if + else_if + 1 = 5 + 1 = 6.
• Forma 3: arestes – nodes + 2 = 19 – 15 + 2 = 6.

Subtipus de requisits no funcionals (RNF):

• Requisits de rendiment (Performance):
  • Rendiment estàtic: S'ocupa de les limitacions de capacitat (ex: "el sistema ha de suportar 100 usuaris concurrents" o "el màxim de jugadors és 10").
  • Rendiment dinàmic: S'ocupa dels temps de resposta i l'eficiència (ex: "el temps de resposta ha de ser inferior a 2 segons").
• Restriccions de disseny (Design Constraints): Són limitacions imposades que restringeixen les opcions del dissenyador. Poden ser de maquinari (HW), programari (SW) o estàndards. Exemple: "L'aplicació s'ha de desenvolupar en Java" o "Només es permeten comptes de Gmail".
• Requisits d'interfícies externes (RIE):
  • Interfície d'usuari: Defineix com interactua l'humà amb la màquina (ex: "l'aplicació estarà disponible en català i anglès").
  • Interfície amb altres mòduls de SW: Com es comunica el sistema amb altres programes (ex: "connexió amb la passarel·la de pagament de PayPal").
  • Interfície amb HW: Com interactua amb dispositius físics.
• Objectius de disseny (Design Goals / Atributs de qualitat): Són desitjos sobre la qualitat final que no sempre són fàcilment mesurables de forma binària (sí/no). Exemples: Usabilitat ("la interfície ha de ser intuïtiva"), Fiabilitat, Seguretat o Disponibilitat.

Introducció a l'Enginyeria del Programari

Software (Programari): Programes d'ordinador, estructures de dades i documentació associada. Els productes de programari poden ser desenvolupats per a un client particular o per a consum massiu.

Productes de programari:

• Genèrics: Sistemes "stand-alone", es poden vendre a qualsevol client (programari d'edició, gràfics, fotografia).
• A mida: Programaris desenvolupats per encàrrec, són específics per tal de satisfer les necessitats del client.

Característiques del programari:

• Es desenvolupa, no es fabrica.
• Manteniment més complex.
• No es deteriora, però esdevé complex.
• Tenir ordinadors més potents ha multiplicat la feina.

Costos:

• Del sistema informàtic.
• Cost de manteniment > desenvolupament.
• L'enginyeria del programari es preocupa del desenvolupament de programari rendible i eficient en costos.

Crisi del programari: Aquesta crisi es va deure a la manca de metodologia, mals hàbits i comunicació no efectiva (client-desenvolupador). Tampoc es feien proves suficients i, per tant, es detectaven els errors molt tard:

• Fora de pressupost.
• Dates de lliurament incomplertes.
• Solució ineficient i/o amb errors.
• Insatisfent requisits.
• Complex de mantenir (gestió del canvi molt complexa).

Enginyeria del Programari: L'enginyeria del programari és una disciplina de l'enginyeria que es preocupa de tots els aspectes de la producció de programari. Pretén desenvolupar un programari de qualitat complint els objectius de cost, que satisfaci l'usuari, funcioni impecablement, i sigui fàcil d'utilitzar i mantenir.

Objectius:

• Cost: Senzill de calcular.
• Qualitat: Aquest depèn de diferents factors (operatius, de revisió i de transició).

Factors operatius (utilització):

• Correctesa: El programa satisfà les especificacions inicials.
• Exactitud: Defineix amb quin grau compleix el programari els requisits.
• Eficiència: Factor referit a l'execució del programari (temps de resposta, requisits de memòria i capacitat de processament).
• Integritat: Control d'accessibilitat al programari per persones no autoritzades.

Factors de revisió (canvis):

• Usabilitat: Esforç necessari per aprendre i utilitzar el programari correctament.
• Mantenibilitat: Esforç necessari per detectar i corregir errors en un programa ja instal·lat.
• Testabilitat: Esforç per provar i assegurar que el sistema o mòdul realitza el seu propòsit.
• Flexibilitat: Esforç necessari per modificar un programa un cop instal·lat.

Factors de transició (adaptació a nous entorns):

• Transportabilitat: Esforç per traspassar el programari d'una configuració de maquinari a una altra.
• Reusabilitat: Fins a quin punt es poden reutilitzar parts del programari per a altres aplicacions.
• Interoperabilitat: Esforç per acoblar el sistema a altres sistemes.

Categories del programari:

• Programari de sistemes: Programes escrits per a altres programes (compiladors, gestors de comunicacions, etc.).
• Aplicacions de programari: Programes "stand-alone" per a necessitats específiques.
• Programari de temps real: Mesura, analitza i controla esdeveniments a mesura que esdevenen.
• Programari de gestió: Processament d'informació comercial.
• WebApps: Aplicacions "en xarxa" basades en entorns web.

Desenvolupament de programari: Elements fonamentals per a la producció.

Elements del desenvolupament:

• Procés: Descriu quines activitats cal realitzar per obtenir programari de qualitat.
• Mètode: Indica com s'han de dur a terme les activitats del procés.
• Eina: Proporciona suport automàtic o semiautomàtic al procés i als mètodes.

Fases en el procés de desenvolupament de programari:

• Anàlisi de requisits: Comprensió del problema i especificació de requisits.
• Disseny: Disseny preliminar (detecció de components i mòduls) i disseny detallat (lògica interna de cada mòdul).
• Codificació.
• Prova: D'unitat, d'integració, de sistema, d'acceptació, de caixa blanca i de caixa negra.

Rols i responsabilitats:

• Executius/ves de desenvolupament: Gestió i organització del projecte.
• Operacions: Suport a l'usuari.
• Cap de projecte: Planificació, assignació de tasques.
• Enginyer/a de Seguretat: Ciberseguretat del programari.
• Tester: Gestió de casos de prova.
• Desenvolupador/a: Back-end.
• Arquitecte/a de BD: Disseny de bases de dades.
• Dissenyador/a UX (Disseny d'Interfície d'Usuari, UI).
• Arquitecte/a: Modelatge de l'arquitectura.
• Analista de sistemes / Analista de negoci: Gestió de requisits.

Paradigmes de Desenvolupament

Paradigma Lineal-Seqüencial (cicle de vida clàssic):

• Esquema visual: Mostra una seqüència en cascada on cada fase té les seves sortides: L'Anàlisi de Requisits genera un Document d'especificació → El Disseny defineix l'Arquitectura del sistema → La Codificació genera els Programes → La Prova genera Docs, Test, Manuals → La Instal·lació genera Docs. d'Instal·lació → Finalitza en el Manteniment.
• Avantatges: Inici i final de cada etapa definits. Documentació detallada. Acord signat dels requisits del sistema.
• Inconvenients: Dificultat per establir explícitament tots els requisits al principi. El client s'haurà d'esperar per veure els resultats. No permet un desenvolupament per etapes.

Construcció de prototips:

• Esquema visual: Es representa un cicle iteratiu de validació (Anàlisi de Requeriments → Disseny → Codificació → Prova → Retorn a l'Anàlisi de Requeriments). Un cop definit, passa a una fase de producció lineal (Disseny → Codificació → Prova). S'hi inclou la imatge d'un esbós de la interfície d'una aplicació mòbil ("wireframe") amb un perfil d'usuari i botons, per il·lustrar un disseny preliminar.
• Característiques: Es desenvolupa a partir d'un conjunt de requisits coneguts. Vol millorar els tres inconvenients del cicle de vida clàssic.
• Formes: Amplada (totes les funcions estan limitades o amb algorismes ineficients) i Profunditat (subconjunt del producte final, funcions problemàtiques).
• Inconvenients: El client ho veu com a programari definitiu. Prototips fets amb recursos inadequats.

Model evolutiu:

• Esquema visual: Mostra un procés dividit en múltiples etapes anomenades "Iteració 1", "Iteració 2" fins a la "Iteració n". Cada iteració inclou un cicle d'Anàlisi de Requisits → Disseny → Codificació → Prova, i cadascuna genera com a resultat un programari "executable" o prototip (Versió 0.1, Versió 0.2...).
• Característiques: El programari es fa per increments i cada increment afegeix una nova funcionalitat. Llista de control del projecte, tasques ordenades sobre què ha d'incorporar la implementació final.
• Limitacions: El manteniment deixa de ser una etapa, es fa al llarg de tot el procés, i és difícil marcar un final.
• Visió incremental: Cada increment és una prova. Molt feedback amb el client (pot implicar inconvenients).

Model en Espiral (The Spiral Model):

• Esquema visual: És un diagrama en forma d'espiral dividit en quatre quadrants: 1. Fixació d'objectius (Objective Setting). 2. Anàlisi i Avaluació de Riscos (Risk Analysis and Evaluation). 3. Desenvolupament (Development/Test). 4. Planificació (Iteration and Planning). L'espiral creix i travessa aquests quadrants diverses vegades fent avançar el projecte en cada cicle.
• Visió en espiral: Afegeix una etapa d'avaluació del risc. Es desenvolupen sis etapes de manera cíclica. A cada cicle s'aconsegueix una versió més sofisticada. Pot mantenir-se operativa sempre.

El Desenvolupament Àgil de Programari

DevOps (Development - Operations):

• Característiques principals: Metodologia basada en increments curts i que aplica integració i desenvolupament continuat.
• Integració contínua: Compilacions i proves d'unitat automatitzades asseguren que els errors siguin detectats de manera precoç.
• Lliurament continu: S'estén amb proves automatitzades dins d'un entorn objectiu, tenint una versió executable del codi integrat.
• Desplegament continu: Les proves i el lliurament automatitzats permeten que les funcionalitats verificables es puguin passar immediatament.
• Operacions contínues: Redueix o elimina la necessitat de temps morts planificats, com ara el manteniment programat; s'alimenta dels predecessors (integració, lliurament, desplegament continus).

Metodologia SCRUM i Filosofia Agile

Filosofia Agile (p. ex. SCRUM):

• Característiques:
  • Minimització de riscos, iteracions molt curtes (14 dies - 28 dies).
  • Comunicació en temps real.
  • Adequat quan els requisits són impredictibles i/o canvien ràpidament.

SCRUM: Entorn àgil de desenvolupament i manteniment de productes complexos. És un procés iteratiu i incremental per optimitzar la predictibilitat i controlar el risc, permet desenvolupar productes en els quals els requisits canvien ràpidament. Basat en treball en equip i autoorganitzat. Permet controlar el caos generat pels conflictes d'interès i necessitats.

Principis:

• Transparència: Procés visible a tothom, es comparteix una mateixa comprensió del producte i dels "fets".
• Inspecció: Inspeccionar els artefactes i el procés cap a l'objectiu.
• Adaptació: Si el procés es desvia dels límits acceptables, s'ha de reajustar.

Característiques de SCRUM:

• Els requisits són elements d'una llista anomenada "product backlog". En aquesta llista els elements es prioritzen i s'estima el seu esforç. Aquests elements s'anomenen "user stories" (històries d'usuari).
• Organitzat en "sprints", petits increments de temps fix (< 1 mes).
• Sprint backlog: Selecció de funcionalitats a implementar.
• Daily scrum meeting: Reunió curta (15 min) diària. Cada membre explica què ha fet, què farà i quins obstacles s'ha trobat. Tothom està convidat però només parlaran el Product Owner, l'SCRUM Master i l'SCRUM team.

Rols:

• Rols compromesos: Aquests rols estan involucrats al 100% amb el projecte; que aquest avanci dependrà d'ells. (Product Owner, Scrum Master, Equip de desenvolupament).
• Rols involucrats: Poden estar involucrats en diversos projectes alhora; el rendiment d'aquest projecte no depèn directament d'ells. (Stakeholders, Usuaris, Direcció).
• Product Owner: Representa el client (actua com a una única veu i té visió del producte). Responsable dels requisits (decideix el Product Backlog, el canvia i el reprioritza). Accepta el programari.
• SCRUM Master: Gestor responsable del procés. Facilita les reunions i monitoritza el progrés. Ajuda l'equip (eliminant obstacles a l'equip, assegurant la productivitat i aïllant l'equip de distraccions). Fa d'interfície entre el Product Owner i l'SCRUM team, i interactua amb la resta de l'organització.
• SCRUM team o Equip de desenvolupament: Té entre 5 i 8 membres, multifuncionals (cadascun té unes experteses). És un equip autònom que s'encarrega de desenvolupar el producte. Responsable dels compromisos i autoorganitzat.

Artefactes (elements):

• Product Backlog: Llista de requisits; no és exacta, pot anar canviant. Han d'estar ordenats segons la prioritat. Pertany al Product Owner, que el pot modificar abans de cada sprint. S'estima la velocitat i l'esforç (dies/hores). S'inclou un gràfic visual d'exemple de "user story" amb el text següent: "STORY 01. As a <user>. I want <feature>. So that <benefit>".
• Sprint Backlog: Subconjunt del Product Backlog: Defineix el treball que es farà al sprint, no pot contenir més de 300 tasques. Creat pel SCRUM team, no pel Product Owner. Té 3 dimensions: Prioritat, Detall i Estat (s'actualitza cada dia).
• Tracking Charts / Gràfiques de progrés: S'utilitzen per monitoritzar el progrés. S'inclouen dues imatges de gràfiques per il·lustrar-ho: una gràfica de "Burn-up" (amb fletxes que indiquen la direcció de les línies de progrés ideal vs actual) i una gràfica de "Software Velocity Burndown Chart" (que mostra una línia blava que descendeix indicant la feina pendent restant en relació amb una línia vermella de progrés ideal al llarg de les setmanes).

Fases de les Iteracions (2-4 setmanes)

Fases:

• Project Kick-off Meeting: Reunió abans de començar el projecte on es decideix la llista de requisits i es crea el Product Backlog.
• Sprint Planning Meeting (planificació del sprint): Seleccionen els requisits a desenvolupar a la iteració, es crea el Sprint Backlog. Tmax = 8 hores i està dividit en dues parts: la primera on es pretén crear el Product Backlog i definir l'objectiu (Product Owner, SCRUM Master i SCRUM Team), i la segona on es vol crear el Sprint Backlog (SCRUM Master i SCRUM Team). També es defineixen les prioritats i s'estima la durada de les tasques.
• Sprint (increment o iteració): Cada dia cal fer el Daily Sprint Meeting (seguiment del sprint).
• Al final del Sprint → Sprint review meeting: Revisió del sprint (l'equip presenta què s'ha aconseguit fer durant el sprint, normalment utilitzant una demo) i es defineix el següent. Participants: Clients, Managers, Product Owners o altres enginyers.
• Sprint Retrospective Meeting: Resum del sprint, només hi participa el SCRUM Team. Serveix com a feedback meeting i es comprova el burn-down chart.

Avantatges i Inconvenients de SCRUM

Avantatges:

• Requisits completament desenvolupats i provats en petits increments.
• Regles ben definides.
• Productivitat incremental i treball autoorganitzat.
• Responsabilitat distribuïda entre l'equip.
• Comunicació activa i fluïda.

Inconvenients:

• Dificultat per determinar el final del projecte.

Escalabilitat

Capacitat de creixement:

• Tot i que és recomanable fer grups petits (6-10 persones), hi ha experts en SCRUM capaços de dirigir grups de 800 persones.
• Diferents equips de desenvolupament treballen junts.
• La freqüència de les reunions es basa en el grau d'acoblament entre grups de tasques.

Altres Models Àgils de Desenvolupament

Lean:

• Manufacturing: Objectius d'analitzar els processos de producció i optimitzar-los per evitar factors que no afegeixen valor i obtenir la màxima qualitat i competitivitat amb el mínim de recursos necessaris.
• Software Development: Adaptació de l'anterior, potenciar l'equip, reaccionar i adaptar-se als canvis el més aviat possible.

Xtreme Programming (XP - Programació Extrema):

Lliurament freqüent (a cada iteració), primer s'escriuen les proves i després s'implementa l'algorisme. Programació en parelles i presència constant del client.

Kanban:

L'objectiu és visualitzar i gestionar el workflow (flux de treball), es limita el treball màxim per etapa, és flexible i adaptable.

Altres models: Crystal, Scrum, Adaptive Software Development (ASD), Feature Driven Development (FDD).

SCRUM vs Kanban

Similituds (moltes):

• Etiqueta = User Story.
• Empren taulell (board).

Diferències:

• SCRUM està orientat a la planificació de tasques.
• Kanban està orientat a gestionar fluxos de treball.
• Kanban és més adequat per a equips orientats a donar suport de programari.

Anàlisi de Requisits del Programari

Dues tasques dins l'etapa d'anàlisi: Comprensió del domini del problema i especificació dels requisits.

Tipus de requisits inicials:

• Requisits d'usuari: Conjunt d'idees que el client té sobre què ha de ser el programari a desenvolupar (prestacions del sistema). Aquestes estan escrites en un llenguatge més natural. Escrits pels clients.
• Requisits del sistema: Document estructurat que estableix descripcions detallades de les funcions, serveis i restriccions operatives del sistema. Normalment, forma part d'un contracte entre el client i el desenvolupador.

Requisits:

Classificació principal

• Funcionals: Aquest tipus de requisits descriuen el comportament desitjat del programari. Expressen una relació entre les entrades i sortides del sistema, especifiquen les sortides que s'han de produir davant de determinades entrades (descrivint les operacions necessàries).
• No funcionals (Restriccions/limitacions): Normalment són quantificables.

Subtipus de Requisits No Funcionals (RNF)

• Requisits de rendiment: Especifiquen restriccions del rendiment del sistema. Es divideixen en:
  • Estàtics: Restriccions sobre característiques d'execució (ex: nombre de terminals, nombre d'usuaris, etc.).
  • Dinàmics: Restriccions sobre el comportament de l'execució del sistema (ex: temps de resposta o velocitat de processament, etc.).
• Restriccions de disseny: Inclouen:
  • Acompliment d'estàndards: Format dels informes, models, etc.
  • Limitacions de maquinari: Disponibilitat de recursos (tipus de plataforma, màquina, SO, etc.).
  • Recuperació i fiabilitat davant d'errors: Pot fer el sistema més complex i car.
  • Seguretat: Utilització de certes comandes, control d'accés a les dades, condicions d'accés per a diferents perfils d'usuari, etc.
• Interfícies externes: Usuari (Interfície UI), Maquinari (Hardware) i Programari (Software).
• Objectius de disseny: Requisits de qualitat. Restriccions generals que incideixen en determinats aspectes de la qualitat final. Els objectius de disseny són més globals.
• Decisions de disseny: Són detalls (de baix nivell) de la implementació ja predefinits abans del disseny.

Tasques principals del procés d'Anàlisi de Requisits:

Fases:

1. Reconeixement del problema → Recollida de requisits.
2. Avaluació i síntesi.
3. Modelització → Especificació: Descripció formal.
4. Especificació.
5. Revisió → Validació.
6. Gestió → Gestió.

Comprensió del domini del problema:

Mètodes de recollida:

• Entrevistes: La més utilitzada i inevitable. Fer entrevistes efectives no és trivial. Tècniques d'entrevista.
• Qüestionaris: Útils per recollir informació d'un grup gran de persones en poc temps. Adequats en situacions amb gran dispersió geogràfica.
• Estudis de documentació: Plans estratègics, normatives, estudis de mercat, etc.
• Observació in situ: Estudi en viu del mode d'operació de l'empresa. Viure el problema des del punt de vista de l'usuari.

Tècniques Addicionals d'Anàlisi

Prototipatge:

• Construcció d'un model o maqueta del sistema.
• Tipus: Esquema en paper o un executable (en amplada o en profunditat).
• Inconvenients: El client ho pot veure com a definitiu i s'ha de fer ràpid (probablement amb recursos inadequats).

Brainstorming (Pluja d'idees):

• Adequat especialment per a la definició de nous productes. L'objectiu és la generació d'idees.
• Fases:
  1. Preparació: Selecció dels participants i el líder de la sessió.
  2. Generació: Es proposa un enunciat general del problema i els participants aporten idees.
  3. Consolidació: Revisar, descartar i prioritzar idees.
  4. Documentació: Generar un document (el líder) on s'indiquen les idees prioritzades.

Mapes conceptuals: Són sinopsis gràfiques d'idees, representades d'una forma jeràrquica.

Casos d'Ús: Especificació de requisits UML, s'intenta especificar un sistema a partir de la interacció amb l'entorn. Permet veure una descripció del sistema des del punt de vista de qui l'utilitza.

Històries d'usuari i escenaris: Són exemples reals de com es pot utilitzar un sistema, són una descripció de com es pot utilitzar el sistema per a una tasca concreta. El journey mapping proporciona una visió concisa i global d'una experiència d'usuari. Permet alinear els diferents stakeholders al voltant d'una visió.

Joint Application Development (JAD): Conjunt de reunions en grup durant un període de 2 a 4 dies. Estalvia temps (els clients no opinen per separat), tot el grup revisa la documentació generada, els clients i usuaris estan més implicats en el desenvolupament. No s'aplica gaire a causa de les necessitats d'organització requerides i el problema d'ajust d'horaris.

Taula Comparativa de Pros i Contres

• Entrevista / Qüestionaris:
  • Pros: Es pot obtenir molta informació. Combinable amb altres tècniques.
  • Contres: Recull informació redundant. Organitzar la informació requereix treball.
• Brainstorming:
  • Pros: Producció d'idees més efectiva que treballant individualment.
  • Contres: Cal una bona dinàmica de grup.
• Casos d'Ús / Prototipus:
  • Pros: Representació dels requisits del sistema des del punt de vista de l'usuari.
  • Contres: En sistemes grans pot requerir molt de temps.
• JAD:
  • Pros: Disminueix malentesos. Evita funcionalitat sobredimensionada. Evita requisits vagues o massa específics.
  • Contres: És costós involucrar totes les parts.

Problemàtica Associada a l'Anàlisi

Problemes:

• Incompletesa. No saber a qui demanar la informació.
• Inconsistència. La informació donada pel client no concorda amb la donada per altres persones.
• La funció i el rendiment poden entrar en conflicte amb altres restriccions.
• La percepció dels objectius del sistema canvia en el temps.
• A mesura que creix la grandària del problema, creix la complexitat de la tasca d'anàlisi.
• El client no acostuma a valorar l'etapa d'anàlisi.

Principis de l'Anàlisi i Modelatge

Principis:

• Partició: S'ha d'estructurar en parts interrelacionades. Les eines que utilitzem han de ser capaces de descriure un problema a partir de les seves parts.
• Abstracció: S'ha de ser capaç de definir una entitat o problema en termes generals. Treure-li tots els detalls, simplificant així la comprensió.
• Projecció: Permet definir el sistema des de diferents punts de vista.

Especificació de Requisits

El resultat de l'anàlisi: És el Document d'Especificació de Requisits (SRS). Aquest document realitza una doble funció: serveix com a contracte i com a base de treball.

Propietats desitjables d'una especificació:

• Especifica el comportament extern, no la implementació.
• Correcta: Cada requisit indicat és un requisit que el programari realment ha de complir.
• Comprensible, no ambigua: Té una única interpretació possible (evitar l'ús de llenguatge natural ambigu).
• Completa: Defineix les respostes del programari a tot tipus de dades d'entrada possibles, defineix tots els termes i unitats de mesura interpretables.
• Consistent: Cap subconjunt dels requisits indicats entra en conflicte.
• Ordenada: Mostra la importància i/o estabilitat de cada requisit.
• Verificable: Existeix un procés finit i de cost assumible; s'ha de poder definir un mètode per verificar un requisit, altrament s'ha de revisar o eliminar.
• Modificable: S'ha de permetre realitzar canvis en els requisits fàcilment, de manera completa i consistent.
• Traçable (que es pot seguir): L'origen ha de ser clar i a cada requisit s'associarà un únic nom, de manera que es puguin referenciar correctament.
• Utilitzable durant l'operació i el manteniment.

Estructura d'un SRS:

1. Prefaci.
2. Introducció.
3. Glossari.
4. Definició de requisits d'usuari.
5. Arquitectura del sistema.
6. Especificació dels requisits del sistema.
7. Models del sistema.
8. Evolució del sistema.
9. Apèndixs.
10. Índexs.

Revisió i validació de l'especificació: Caldrà fer una reunió d'experts que intenten valorar la qualitat del resultat (a dos nivells):

• Macroscòpic: Comprovar si l'especificació és completa, consistent i precisa.
• Detallat: Precisar termes concrets.

Disseny del Programari

Què és el Disseny i l'Anàlisi?

Què és el Disseny?: Tasca de descriure com ha de ser el sistema. Té com a objectiu produir un model o representació del sistema perquè aquest pugui ser utilitzat. Es concentra en construir una arquitectura que doni suport al sistema per tal de garantir tots els requisits.

Anàlisi-Disseny: L'Anàlisi de Requisits permet definir QUÈ. El Disseny descriu COM ha de ser el sistema (expressant la seva arquitectura i descrivint tots els detalls tècnics).

Canvi de model (per entendre les necessitats del client):

• Model de negoci.
• Processos de negoci.
• Problema que es vol resoldre.
• Beneficis que es poden proporcionar.

Arquitectura i Disseny

Arquitectura (bona arquitectura): Permet construir el sistema de manera que encaixi amb l'entorn i s'adapti als canvis quan aquest canviï. També ha de permetre funcionar al sistema de forma fiable i ajudar a gestionar la complexitat del sistema.

Objectius de l'arquitectura:

• Organitzatiu: Ajuda a comunicar (descriure) el disseny d'alt nivell, proporcionar el context (de desenvolupament) als enginyers, i assignar tasques (a l'equip de desenvolupament).
• Tècnic: Associa els requisits del sistema amb objectius concrets, possibilita la distribució flexible del sistema, redueix el cost del manteniment i l'evolució del sistema, i incrementa la reutilització i la integració d'altres elements.

Definició del Disseny de Programari: És el conjunt de decisions que permeten definir l'estructura interna que tindrà el sistema per donar suport als requisits. L'estructura del sistema està formada per les parts en què es divideix i les interrelacions entre aquestes parts.

Cost: Aquest està mesurat pel seu impacte estratègic.

Àmbit de les decisions (garantir la integritat del sistema):

• Estructural: El sistema ha de ser robust i resistent respecte als errors.
• En el disseny: Certificar la integritat conceptual i la coherència de tots els requisits del sistema.
• Organitzativa: Assegurant que les decisions de disseny estiguin alineades amb els valors de l'organització.

Nivells de disseny:

• Disseny preliminar: Transformació de les dades segons els requisits i en l'arquitectura del programari.
• Disseny detallat: Conceptes mais específics, refinament de l'estructura de dades i definició dels mòduls i les seves relacions.

Tipus de disseny:

• Disseny de Dades: Transforma el model de dades de l'anàlisi en les estructures de dades que s'utilitzaran en el sistema.
• Disseny Arquitectònic: Defineix la relació entre els principals elements.
• Disseny Procedimental: Genera una descripció procedimental dels elements de programari.
• Disseny d'Interfície: Descriu com es comunica el programari (amb ell mateix, amb sistemes externs, i amb els usuaris).

Processos i Conceptes de Disseny

Estructuració: Cal anar construint l'estructura del mateix de forma iterativa assegurant en cada pas que el seu comportament satisfà els requisits. També s'ha de definir el disseny de les parts i les seves interrelacions.

Mòduls: Els mòduls són les parts en què es divideix el sistema; aquests són finits, identificables i lògicament separables. Poden ser una funció, un conjunt de dades i les seves funcions associades, etc.

Dividir en mòduls petits implica: incrementar el nombre d'elements del sistema, augmentar la interdependència dels mòduls i dificultar la detecció i correcció d'errors entre mòduls.

Conceptes:

• Independència funcional: Cada mòdul ha de tenir un impacte mínim sobre la resta.
• Interrelacions - Interfícies: Les interrelacions entre mòduls estan definides amb interfícies. Aquestes representen abstraccions dels mòduls que els aïllen d'altres mòduls. Les abstraccions descriuen el comportament extern dels mòduls i eviten que les dependències es propaguin.

Tipus d'abstracció a les interfícies:

1. Abstracció funcional: Des del punt de vista de la funció que realitza.
2. Abstracció de dades: Col·lecció de dades que descriuen un objecte de dades.
3. Abstracció de control: Implica un mecanisme de control del programa sense especificar detalls interns.

Cohesió: Buscarem que sigui alta. Defineix a quin nivell treballen conjuntament els mòduls; l'estructura del programari determina el grau de cohesió dels diferents mòduls.

Nivells de cohesió (ordenats de Baixa a Alta segons el gràfic):

• Coincidental: Tasques poc relacionades.
• Lògica: Tasques relacionades lògicament.
• Temporal: Tasques que s'han d'executar durant el mateix període de temps.
• Procedimental: Partició a partir del diagrama de flux, és a dir, elements relacionats que s'executen en un ordre específic.
• Comunicacional: Tasques que operen sobre les mateixes dades.
• Seqüencial: Les dades resultat de cada element de processament del mòdul són l'entrada del següent element.
• Funcional: Tots els elements del mòdul es relacionen per realitzar una única funció.

Acoblament

Definició: Acoblament (buscarem que sigui baix): Mesura de la interdependència entre mòduls i la manera com s'organitzen les dependències.

Espectre de l'acoblament (ordenats de Baix a Alt segons el gràfic):

• Sense acoblament directe.
• Acoblament de dades: Dos mòduls es comuniquen amb paràmetres on cadascun és una dada simple o bé un conjunt de dades homogènies.
• Acoblament de marca (per registre): Un mòdul passa a un altre un registre o estructura de dades no homogènia (amb diferents camps). Cal una comprovació de les estructures de dades. Per altra banda, cal evitar passar registres amb molts camps dels quals només se n'utilitza algun.
• Acoblament de control: Un mòdul passa un paràmetre a un l'altre amb la intenció de controlar el seu comportament.
• Acoblament comú: Diversos mòduls accedeixen a la mateixa àrea global de dades.
• Acoblament de contingut: Un mòdul accedeix directament i sense control a una part d'un altre mòdul.

Reutilització del Disseny i Arquitectura

Reutilització del disseny: És un objectiu desitjable i es pot fer a diferents nivells i en diferents àrees. Podem reutilitzar: Patrons d'arquitectura (solucions generals i reusables que s'apliquen a problemes comuns, similars als Patrons de Disseny de programari).

Patrons d'arquitectura (s'inclouen esquemes visuals per a cadascun):

• Layered (Capes): Representat visualment amb capes horitzontals superposades.
• Pipe-filter: Representat visualment amb nodes (filtres) connectats de forma seqüencial.
• Client-Servidor: Representat amb icones de pantalles d'usuari (clients) connectant-se a través d'un núvol a una icona de servidor.
• Model-View-Controller (MVC): Representat amb un esquema de relació triangular entre els tres components.
• Event-Driven Architecture (Arquitectura orientada a esdeveniments): Esquema on diversos mòduls es comuniquen a través d'un "Event Channel" central. Permet construir sistemes distribuïts capaços de rebre missatges, són fàcilment escalables i aplicacions de comerç electrònic (e-commerce).

Arquitectura de Microserveis

Característiques: Cada servei es desplega independentment i té la seva pròpia API. S'utilitza en centres de dades corporatius amb límits.

Esquema visual: S'inclou un diagrama on un usuari "Client" es connecta a una "API gateway". Aquesta passarel·la es comunica amb un gran bloc de serveis que inclou mòduls com "Catalog Service" i "Review Service". A sota hi ha un mòdul de "Management/Orchestration" i a la dreta un usuari amb el rol "DevOps" connectat al sistema.

Patrons de Disseny

Definició: Tècniques de modelatge del programari que permeten solucionar diferents problemes en diferents àmbits utilitzant estructures o models de classes preestablerts; són 'una forma de reutilitzar el disseny'. Són similars als Patrons d'Arquitectura però tenen un abast més específic.

Conceptes i Aplicació:

• Abstracció: Una solució abstracta serà un conjunt de classes abstractes que es relacionen entre elles; per tant, el mateix disseny abstracte es podria reutilitzar.
• Aplicació del model: Dividirem el model en una part abstracta i una part particular.

Elements: La descripció de cada patró (pattern) conté, entre d'altres:

• Nom: Nom del patró, permet descriure el problema de forma unívoca.
• Problema: Descripció d'aquest.
• Solució: Disseny d'un conjunt de classes abstractes i particulars; funciona com a plantilla per implementar la determinada solució.

Objectius:

• Evitar la reiteració de recerca de solucions.
• Reutilització d'un catàleg de dissenys (permet un vocabulari comú entre dissenyadors, estandardització del procés i reutilització de classes).

Catàleg de Patrons de Disseny

Explica els principis i descriu una col·lecció bàsica (catàleg) dividit en tres grups:

1. De creació (Proporcionen mecanismes de creació d'objectes)

• Factory Method: Els objectes no són instanciats directament sinó que deleguem en un altre la seva construcció. Crea instàncies d'una classe sense conèixer la subclasse particular. Disminueix l'acoblament del disseny.
• Abstract Factory: Proveeix una interfície de famílies d'objectes relacionats, que s'instancien a través d'una factoria comuna.
• Builder: Separa la creació d'un objecte complex de la seva representació; el mateix procés de creació pot donar pas a diferents representacions. Millora l'extensibilitat i reusabilitat del codi.
• Prototype: Crea nous objectes duplicant-ne d'altres d'existents (clonació). És útil per especificar en temps d'execució el tipus de la classe.
• Singleton: Garanteix que la classe només pot tenir una única instància i la classe mai pot ser instanciada fora de la mateixa classe.

2. Estructurals (Proporcionen mecanismes per relacionar instàncies)

• Adapter: Proveeix una classe amb un conjunt d'operacions diferents del que oferia originalment. Adapta una interfície ja existent sense canviar-la perquè d'altres la puguin utilitzar.
• Bridge: Desacobla abstraccions de les implementacions. Els canvis en les abstraccions no poden afectar la implementació i viceversa.
• Composite: Agrupa objectes amb estructura d'arbre per representar jerarquies de part-tot. Aplicable a objectes amb jerarquies recursives de tipus arbre.
• Decorator: Afegeix dinàmicament nou comportament a un objecte sense que s'alteri el comportament de la resta d'objectes de la mateixa classe.
• Facade: Defineix una interfície d'alt nivell simplificada que fa més senzill utilitzar un codi complex. Actua com a classe biblioteca.
• Flyweight: Elimina o redueix la redundància de dades amb informació idèntica. Equilibri entre flexibilitat i rendiment. Disminució en l'ús de recursos.
• Proxy: Proporciona un substitut o representant d'un altre objecte per controlar l'accés a aquest. S'utilitza quan es vol tenir una referència a un objecte més flexible i sofisticada que un punter.

3. De comportament (Proporcionen mecanismes per comunicar objectes i la seva interacció)

• Chain of Responsibility: Solució a l'acoblament entre una petició i el seu receptor en temps d'execució. Proporciona a més d'un objecte la possibilitat de respondre a la petició.
• Strategy: Dins d'un conjunt d'algorismes s'encapsula cadascun d'ells per fer-los intercanviables, i en temps d'execució se selecciona quin utilitzar. Les decisions per escollir poden venir del client o del mateix objecte.
• Observer: Permet observar l'estat d'un objecte des d'altres elements.
• Iterator: Proporciona un mètode d'accedir de forma seqüencial els elements d'un objecte agregat sense haver de conèixer la seva representació interna.
• Template Method: Permet definir un comportament específic dins la superclasse, i delegar la implementació d'alguns mètodes dins les subclasses reescrivint el comportament.
• Memento: Representa i externalitza l'estat intern d'un objecte sense violar l'encapsulació. L'objecte podrà tornar al seu estat anterior.

Gestió del Disseny de Programari

Problemes de degradació:

• Canvis de requisits: Un dels principals problemes que provoquen la degradació del programari; per això, és molt important que el disseny implementat faciliti la gestió dels canvis associats als canvis en els requisits del sistema.
• Gestió de dependències: Una altra causa important que provoca la degradació del programari (qualsevol canvi en un mòdul pot tenir efectes en altres mòduls relacionats). Voldrem evitar que aquestes dependències es propaguin.
• Codi rígid (difícil de canviar): Pot provocar canvis en cascada i que es desconeguin les conseqüències dels canvis.
• Codi fràgil (fàcil de trencar): Al fer un canvi a un mòdul es produeixen errors a altres.
• Codi inamovible (difícil de reusar): Es dóna quan el codi està molt acoblat.
• Codi viscós (difícil d'implementar el disseny): Els resultats acostumen a ser fràgils.
• Complexitat innecessària: Aplicar massa patrons de disseny per resoldre un problema simple.
• Codi repetit.
• No implementar cap disseny.

Principis de Disseny de Programari

Principis fonamentals:

• Disseny orientat a objectes: Ajuda a organitzar el programari de forma eficient i permet gestionar les dependències per evitar escriure mòduls rígids, fràgils i no reusables. Fent que un mòdul cridi a un altre i que en temps de compilació la dependència apunti en direcció contrària al flux de control.
• Principis 'SOLID' en el disseny:
  • SRP (Single Responsibility Principle): Tota classe ha de ser cohesiva i tenir només una responsabilitat.
  • OCP (Open/Closed Principle): Les classes d'un mòdul haurien d'estar obertes per poder estendre la seva funcionalitat, i tancades per evitar canvis.
  • LSP (Liskov Substitution Principle): Qualsevol classe derivada sempre hauria de poder usar-se en comptes de la seva classe base, sense que l'usuari hagi de saber la diferència.
  • ISP (Interface Segregation Principle): Permet crear interfícies específiques per evitar dependències innecessàries i permet incrementar la cohesió.
  • DIP (Dependency Inversion Principle): Els mòduls d'alt nivell no haurien de dependre dels mòduls de baix nivell; permet disminuir la rigidesa del disseny i l'acoblament entre mòduls. Utilitzarem la tècnica d'injecció de dependències (Dependency Injection, DI).

Regles de Disseny:

• Dry principle (Don't Repeat Yourself): Cada part del coneixement ha de tenir una representació simple i no ambigua. Incrementa la mantenibilitat i la testabilitat del codi.
• Regles que hauria de seguir un bon disseny: S'ha de poder validar i ha d'estar ben cobert per un conjunt de tests; han de tenir només les abstraccions necessàries. També han de tenir un comportament no ambigu i el menor nombre possible de conceptes.

Disseny d'Interfícies d'Usuari

Tipus d'Interfícies d'usuari: GUI (Graphical User Interface), CLI (Command Line Interface), TUI (Text User Interface), WEB (Interfície per a WEB).

Principis de les UI: La interfície ha d'estar ben feta perquè modela la percepció que l'usuari té del programari. Ha de millorar l'eficiència, evitar la frustració de l'usuari (cometre errors) i s'ha d'adaptar a l'humà, no a l'inrevés.

Regles daurades (principis fonamentals):

1. Deixar el control a l'usuari, no obligar l'usuari a fer accions no desitjades.
2. Reduir la necessitat de memoritzar, definir dreceres i mostrar la informació de manera progressiva.
3. Fer una interfície senzilla i consistent; tot el programari ha de seguir les mateixes regles de disseny.

Usabilitat i Procés:

• Usabilitat: Mesura com el programari facilita l'aprenentatge, ajuda l'usuari a recordar, redueix la possibilitat de cometre errors, i augmenta l'eficiència.
• Procés: Model en Espiral (iteratiu).

Model en Espiral (Disseny d'Interfícies):

• Esquema visual: Es mostra un diagrama d'espiral dividit en quatre quadrants que representen el cicle iteratiu del disseny d'interfícies: Anàlisi → Disseny → Implementació → Validació.
• Anàlisi de les interfícies d'usuari:
  • Anàlisi de la interfície: Quins perfils d'usuaris (entrevistes, anàlisi de mercat...), quines tasques a fer (casos d'ús), anàlisi del flux de treball, anàlisi del contingut de la pantalla i format (estètica), ambient de treball.
  • Anàlisi del Disseny: Definir objectes i accions, distribució de la pantalla (disseny gràfic, col·locació d'icones, descripció del text), escenari d'ús.
• Disseny de les interfícies d'usuari:
  • Etapes: Definir objectes i accions (operacions). Definir quines accions de l'usuari (esdeveniments) canvien l'estat de la interfície. Il·lustrar cada estat de la interfície (com es veuria).
  • Aspectes del disseny que cal treballar: Temps de resposta (massa alt en eines molt interactives), eines d'ajuda (què, quan i com), gestionar els errors (informació útil i constructiva), llegendes del menú i comandes (ex. Ctrl+C), accessibilitat de l'aplicació, internacionalització (idioma, codificació del text).
• Avaluació del disseny de la interfície: S'avalua el prototipus → feedback de l'usuari. S'empren tècniques formals d'avaluació per avaluar la complexitat i la usabilitat:
  • Aspectes qualitatius: Resposta sí/no, escala numèrica.
  • Aspectes quantitatius: Nombre de tasques realitzades i temps emprat per a cada tasca, nombre d'errors comesos.
  • Es fa una altra volta a l'espiral (anàlisi, disseny...) i aquest cicle continua fins que la interfície és satisfactòria.

Qualitat del Programari, Proves i Verificació

Test i Verificació

Definició: Test: Avaluació d'un sistema de forma manual o automàtica per tal de verificar que satisfà els requisits especificats.

Importància del Test:

• Per què?: A l'hora d'implementar un sistema sempre hi ha errors i, per tant, s'ha de poder garantir que el sistema es comporta com s'espera.
• Conseqüències?: El cost de corregir un error és menor com més aviat es troba, perquè el disseny no està completament definit i és més fàcil fer-hi canvis.

Fases de Testing

Diferències entre mètodes:

• Fase de Testing: Perquè no és el mateix testejar que tenir tests automatitzats. La diferència és aconseguir l'exhaustivitat de les proves (la qual resulta necessària per garantir la qualitat del programari).
• Tests manuals: Comprovar un programari de manera manual és inviable, ja que requereix molts recursos personals, consumeix molt de temps i deriva en molts errors.
• Tests automàtics: Permeten conèixer de manera ràpida si el programari funciona correctament, permeten revisar immediatament si els canvis han generat nous errors i acceleren el temps de desenvolupament.

Piràmides de Tests

Esquema visual: Es mostren dues piràmides que comparen l'estratègia de proves.

• Piràmide invertida (males pràctiques): Té una base petita d'Unit Tests i una part superior molt gran de Manual Testing, indicant un alt cost i temps d'execució.
• Piràmide ideal: Té una base ampla de "Automated Unit Tests", seguida de proves de components, integració, API, GUI i, finalment, una punta mínima de "Manual Session Based Testing". Una fletxa indica que a mesura que pugem en la piràmide, el cost i el temps d'execució augmenten.

Proves de Caixa Blanca i Caixa Negra

Proves de Caixa Blanca: Es realitzen quan es coneix l'estructura interna del programari i permeten realitzar un examen minuciós de la lògica interna. Té com a objectius garantir que s'executen totes les línies de codi, s'utilitzen correctament les estructures de dades i porten al límit l'execució dels bucles.

• Tests Unitaris: Garanteixen que la unitat funciona; aquesta unitat pot ser una funció d'una classe.
• Test d'integració: Garanteixen que diferents mòduls del sistema funcionen adequadament de forma conjunta.

Proves de Caixa Negra: Es realitzen quan no es coneix l'estructura interna del programari i permeten comprovar el comportament del sistema i que es compleixen els requisits. Els seus objectius són garantir que les interfícies internes funcionen correctament, l'accés a bases de dades i serveis externs, i que no hi ha errors (rendiment, inicialització, etc.).

• Tests de contacte: Un mòdul en concret (el consumidor) necessita la funcionalitat proporcionada per un altre mòdul (el productor); aquest proporciona la funcionalitat a través d'una interfície.
• Tests de UI: Garanteixen que la interfície d'usuari funciona correctament (comportament, renderització, usabilitat).
• Tests End-to-End (E2E): Comproven el sistema complet, assegurant que funciona correctament en l'entorn de producció; quan fallen és difícil conèixer la causa de l'error.
• Tests Funcionals (d'acceptació): Asseguren que l'aplicació funciona correctament des del punt de vista de l'usuari.
• Tests d'exploració: Permeten comprovar el comportament en situacions estranyes intentant provocar errors.

Models de Desenvolupament i Proves

En Cascada:

• L'àmbit dels tests, l'estratègia i el pla de test es defineixen a la fase d'anàlisi.
• Avantatges: Fàcil d'implementar i mantenir. Fase inicial molt rigorosa que ajuda a guanyar temps en la fase de desenvolupament.
• Inconvenients: No és possible canviar els requisits. No es pot avançar a la següent fase fins a completar la prèvia.

En V:

• Model incremental, té una fase de test associada a cada fase de desenvolupament, es fa en paral·lel.
• Avantatges: Els defectes de disseny es detecten en fases inicials.
• Inconvenients: El client veu el producte com a acabat. Els errors en els requisits es detecten al final.

Agile:

• Demana molta implicació dels stakeholders i els clients, però permet tenir feedback durant el desenvolupament. Permet tenir un sistema estable des de l'inici.
• Avantatges: Garanteix la satisfacció del client. És flexible. Proporciona ràpidament programari que funciona (sense errors). Permet adaptar-se a canvis.
• Inconvenients: En projectes grans i complexos és difícil predir l'esforç necessari. El projecte pot quedar encallat si no té perfectament definits els objectius.

Metodologia Àgil de Proves

Esquema visual (Agile Testing Quadrants): Es mostra una matriu de quatre quadrants (Q1 a Q4) que divideix els tests segons si estan orientats a la tecnologia o al negoci, i si donen suport a l'equip o critiquen el producte.

• Q1 (Tecnologia/Equip): Unit Tests, Component Tests.
• Q2 (Negoci/Equip): Functional Testing, Story Tests, Prototypes.
• Q3 (Negoci/Producte): Exploratory Testing, Scenarios, UAT (User Acceptance Testing).
• Q4 (Tecnologia/Producte): Performance & Load Testing, Security Testing, "ility" Testing.

Disseny de les Proves

Què cal fer?: S'han de definir els casos de prova (què és el que es prova i com es provarà) i l'execució de les proves (s'executa el test per a cada cas i s'avalua la desviació de la sortida). Limitació de les proves: És gairebé impossible comprovar totes les condicions; per això, cal seleccionar bé els casos de prova per cobrir el màxim de situacions.

Complexitat de les Proves:

• Reducció de la complexitat 'Caixa Blanca': Cal reduir els diferents camins d'execució i llavors serà suficient contemplar els casos que passen una vegada.

Camins Bàsics (Pas a pas):

• Pas 1: Simplificar el graf.
• Pas 2: Complexitat ciclomàtica V(G). Camí d'execució independent: Qualsevol camí del programa que introdueixi almenys un nou conjunt de sentències en l'execució o una nova condició.
• Fórmules de V(G):
  1. Nombre de regions del graf de flux (l'exterior compta com a una regió).
  2. Nombre d'arcs - nombre de nodes + 2.
  3. Nombre de nodes condició + 1.
• Pas 3: Trobar un possible conjunt de camins independents amb cardinalitat V(G). Camins independents: Aquells que afegeixen nodes nous al camí.
• Pas 4: Determinar un cas de prova per a cada camí independent. Determinar uns valors per a les variables de manera que l'execució del programa recorri el camí (independent) donat.
• Pas 5: Executar el codi comprovant si el resultat és o no l'esperat. Durant el disseny dels casos de prova cal calcular els resultats esperats de l'execució de la prova per tal de fer una comparació amb els resultats obtinguts.

Bucles: Es concentra exclusivament en la validesa de les construccions dels bucles. Es distingeixen quatre classes diferents de bucles:

• Simples:
  1. Passar per alt el bucle.
  2. Passar només una vegada pel bucle.
  3. Passar dues vegades pel bucle.
  4. Fer m passos pel bucle (m < n).
  5. Fer n-1, n i n+1 passos pel bucle.
• Niuats: Començar fent les proves de bucle simple amb el més intern, configurant la resta amb els seus valors mínims i també amb valors fora de rang. Progressar cap a fora de la mateixa manera, configurant els bucles interns amb els seus valors més típics.
• Concatenats i no estructurats:
  1. Si són bucles independents es poden fer proves de bucle simple.
  2. Si no són bucles independents es recomanen les proves per als bucles niuats.

Flux de dades: Seleccionar camins de prova d'acord amb la ubicació de les definicions i l'ús de les variables d'un programa.

Implementació de Proves de Caixa Negra

Partició equivalent: No podem derivar tots els casos, cal seleccionar un nombre representatiu de casos de prova.

• Classes d'equivalència: La prova d'un element de la classe troba els mateixos errors que qualsevol altre element d'aquesta; això redueix el nombre de casos de prova. Exemple: sqrt(x) on x >= 0 és vàlida.

Altres mètodes de Caixa Negra:

• Derivació directa de casos de prova (Valor límit): Coneixement empíric: Els errors tendeixen a donar-se amb més freqüència a les "fronteres" de les classes d'equivalència que en el seu "centre".
• Comparació: Diferents equips desenvolupen per separat el programari a partir de les mateixes especificacions i totes les versions es comproven amb les mateixes dades de prova.
• Per a entorns i aplicacions especials: En determinats àmbits es poden fer proves específiques del domini: per a interfícies gràfiques d'usuari, per a sistemes en temps real, per a arquitectures client/servidor, o per a fluxos de dades en temps real.

Nivells de les Proves

Fases de verificació:

• Proves de components (unitats): Verificació de mòduls, amb un component principal de Caixa Blanca a diferents nivells de detall. Realitzat per l'equip desenvolupador.
• Proves d'integració: Si un conjunt de mòduls funciona bé per separat, per què no quan s'ajunten? Utilitzarem la integració incremental, la qual implica crear controladors (drivers) i resguards (stubs). Cal fer servir tant tècniques de Caixa Blanca como de Caixa Negra. Realitzat per l'equip desenvolupador.
• Proves de sistemes: Es prova el sistema com un tot, comprovant si hi ha desviacions del seu comportament respecte dels requisits. Realitzat per l'equip desenvolupador i els responsables del sistema.
• Proves d'acceptació: Comprova si es proporcionen les funcionalitats que el client i l'equip de desenvolupament van acordar. Primer ho fa l'equip desenvolupador, després els usuaris. Inclou diverses proves individuals:
  • Proves de camp: Prova d'una versió beta (pre-release) en condicions reals.
  • Proves d'acceptació de l'usuari (UAT): Usuaris reals proven el sistema.
  • Proves alfa: Fetes al lloc de desenvolupament; un client prova el sistema i els desenvolupadors l'observen. Entorn controlat.
  • Proves beta: Fetes al lloc de treball de l'usuari final, per ells mateixos. Els usuaris registren tots els problemes observats. Entorn no controlat.
  • Acceptació respecte al contracte: Es proven les condicions incloses al contracte per donar el servei com a acceptat per part del client.

Qui ha de fer cada Prova?

Esquema visual: Es mostra un diagrama de flux (similar al Model en V) que connecta les fases de disseny amb les seves respectives proves:

• Especificació de requeriments → Criteris d'acceptació → Proves d'acceptació (primer: equip desenvolupador o grup independent de prova; després: usuari/s).
• Disseny de l'arquitectura → Proves de sistema (equip desenvolupador i responsables del sistema).
• Disseny de components → Proves d'integració (equip desenvolupador).
• Implementació → Proves de components (equip desenvolupador).

Proves amb Orientació a Objectes

Característiques:

• La unitat de la prova (el context de la seva classe és important).
• L'herència implica més proves.
• L'encapsulament dificulta conèixer l'estat dels objectes.
• Polimorfisme (templates C++).

Proves d'unitat: Proves a nivell de classe: S'ha de verificar que la implementació d'una classe es correspon amb la seva especificació.

1. Identificar casos de prova.
2. Implementar un Test Driver (programa que executa casos de prova) que executi cadascun dels casos de prova i compari el resultat.

POO: Implementació d'un Test Driver:

• Avantatges: Codi del driver a prop del codi de la classe (main()). Facilitat de reutilització en classes derivades i millor organització de les funcions de suport i de casos de prova (classe separada Ctester).
• Inconvenients: Necessitat de compilació condicional i codi del driver difícil de reutilitzar (main()). Cal crear una nova classe i posar més atenció a propagar els canvis de la classe original al driver (classe separada Ctester).

Com identificar les interaccions entre (objectes de) classes?:

1. Una operació esmenta una o més classes com el tipus d'un dels seus paràmetres.
2. Una operació esmenta una classe com el tipus de retorn de valor.
3. Una funció membre crea una instància d'una altra classe com a part de la seva implementació.

Definició i Escenaris de Proves

Definició de casos de prova basada en requisits:

• Definició basada en codi: L'estructura del codi serveix com a referència (Caixa Blanca).
• Definició basada en especificacions: Es consideren les entrades i sortides, no la implementació (Caixa Negra).

Escenari de cas de prova: Especifica interaccions a diferents nivells d'abstracció, és a dir, tipus d'entrades, tipus de sortides esperades, i les interaccions entre els tipus d'actors implicats en la prova.

• Escenaris interns al sistema: Proves de components i proves d'integració.
• Escenaris d'interacció: Proves de sistema (es proven les interaccions del sistema amb els usuaris o altres sistemes).
• Escenaris de context: Proves d'acceptació.