Exercicis: El procés de desenvolupament

Aquestes fases del desenvolupament d'un programa estan desordenades: (a) provar el programa amb diferents dades, (b) editar el codi font, (c) depurar els errors trobats, (d) executar el programa. Ordena-les de manera raonable i explica què es fa en cadascuna, tenint en compte que en provar pot ser necessari tornar enrere.

Explica què és un «bug» en un programa i què és depurar. Posa un exemple senzill d'error que podria tenir el programa d'un caixer automàtic i quina conseqüència tindria per a l'usuari.

La figura mostra el cicle de treball del desenvolupament d'un programa, però una de les seves etapes està tapada amb un signe d'interrogació, com es mostra a la figura.

Indica quina etapa falta dins del cicle, en què consisteix i per què la fletxa de «no» retorna la feina a l'edició del codi.

Explica què és un missatge de traça o registre (log) en un programa i com ajuda a trobar un error (permet veure per on ha passat el programa i amb quins valors).

Els programes tenen versions (1.0, 1.1, 2.0...). Explica per a què serveix guardar versions del codi i què pots fer si l'última versió funciona pitjor que l'anterior.

Explica què és un cas de prova i escriu dos casos per a un programa que suma dos nombres: un amb valors normals i un altre amb algun valor especial, indicant l'entrada i el resultat esperat de cadascun.

La documentació acompanya el programa. Explica quines dues coses hauria d'explicar com a mínim (què fa el programa i com s'utilitza) i per què un programa sense documentar «envelleix» malament quan treballa un equip.

Distingeix entre un error que apareix en compilar (el programa ni tan sols arrenca) i un error que apareix en execució (arrenca però falla amb certes dades), amb un exemple de cada tipus.

Explica la diferència entre un error de sintaxi i un error de lògica, amb un exemple de cada tipus en un programa que calcula la mitjana de tres notes. Quin dels dos tipus impedeix executar el programa i quin deixa executar-lo però dona resultats incorrectes?

Un programa que divideix dos nombres funciona bé en gairebé totes les proves, però falla quan el divisor és 0. Explica què són els valors límit o casos especials en les proves, per què cal provar-los sempre i esmenta dos valors més amb què provaries aquest programa.

Explica què és la modularització d'un programa (dividir-lo en funcions o mòduls) i analitza dos avantatges que aporta quan el desenvolupament el fa un equip de diverses persones: pensa en el repartiment de la feina, en les proves i en la localització d'errors.

Un bucle d'un programa no s'atura mai. Explica on col·locaries missatges d'escriptura temporals per diagnosticar-lo (dins del bucle, mostrant la variable de control a cada volta) i què observaries en aquests missatges per trobar la causa.

Per provar un programa que aplica un descompte a persones de 65 anys o més, defineix tres casos de prova: un amb un valor normal, un amb el valor límit exacte i un amb un valor erroni (edat negativa o impossible), amb el resultat esperat de cadascun. Justifica les teves eleccions.

Explica què és refactoritzar (millorar el codi sense canviar el que fa) i descriu dues refactoritzacions típiques (canviar el nom de variables per noms clars, extreure una funció a partir de codi repetit), amb un exemple de cadascuna.

Un fragment de codi utilitza les variables x, y2 i zzz per guardar el preu, l'IVA i el total. Reescriu aquests noms de manera significativa i explica per què l'elecció de noms és una eina contra els errors (el codi s'autodocumenta).

Dues persones d'un equip editen alhora el mateix fitxer del projecte i, en unir els canvis, apareix un conflicte. Explica què és un conflicte de fusió, com es resol (revisar ambdues versions i decidir) i quins dos hàbits de treball en equip el prevenen (repartir la feina per mòduls, integrar els canvis sovint).

En el sistema de cobrament d'una cooperativa escolar s'ha detectat que, en emetre la factura mensual, el total a pagar d'alguns socis és erroni. Disposes dels registres del sistema següents:

• Soci 101: 2 compres de 15,00 € -> Total cobrat: 30,00 € (esperat: 30,00 €).

• Soci 102: 1 compra de 50,00 € amb descompte promocional del 10 % (5,00 €) i recàrrec per despeses de gestió de 3,00 € -> Total cobrat: 47,50 € (esperat: 48,00 €).

• Soci 103: 1 compra de 20,00 € i devolució d'1 article de 5,00 € (-5,00 €) -> Total cobrat: 25,00 € (esperat: 15,00 €).

• Formula una hipòtesi justificada sobre la fallada lògica o d'ordre d'operacions que explica l'error en el Soci 102 i en el Soci 103.

• Dissenya l'estratègia de depuració per confirmar les teves hipòtesis: indica quines dades de prova mínimes introduiries per aïllar la fallada, en quins punts del flux situaries punts d'interrupció (breakpoints) i quines variables concretes hauries d'inspeccionar pas a pas.

Un company d'equip et mostra la funció següent en C++ per calcular el preu final amb IVA i aplicar un descompte si el client és soci, assegurant: «Si compila sense errors ni advertiments, és impossible que falli en execució; no cal provar-la»:

float calcularPrecioFinal(float base, bool esSocio) {

    float total = base;

    if (esSocio = true) {

        total = total * 0.90f;

    }

    total = total * 1.21f;

    return total;

}

1. Prediu raonadament la sortida de la funció per a un client no soci (esSocio = false) amb una base de 100,00 €. Coincideix amb el comportament esperat? Explica per què el compilador no ho rebutja com a error.

2. Justifica, a partir d'aquest exemple, la diferència entre el que garanteix la verificació sintàctica del compilador i el que demostren les proves dinàmiques de programari.

3. Proposa la correcció del codi i escriu un cas de prova concret que evidenciï la fallada si la correcció no estigués aplicada.

Dissenya un pla de proves per a un programa que demana dos nombres i mostra la seva divisió: fes una taula amb almenys sis casos de prova (parells de valors d'entrada, incloent valors normals, límit i erronis), el resultat esperat de cadascun i què hauria de fer el programa si l'entrada no és vàlida. Justifica l'elecció de cada cas.

Un script de simulació meteorològica falla aproximadament una de cada vint execucions llançant una excepció inesperada, però en executar-lo manualment pas a pas mai no reprodueix la fallada (el programa utilitza peticions a una API en temps real i una funció de generació de nombres aleatoris).

1. Justifica per què aquest error es classifica com a no determinista (heisenbug) i identifica les dues fonts de variabilitat que impedeixen reproduir-lo a voluntat.

2. Dissenya un pla d'actuació tècnic per forçar la reproducció controlada de la fallada sense esperar passivament que passi a l'atzar (explica com tractaries el generador de nombres pseudoaleatoris i com desacoblaries les crides de xarxa externes).

3. Un cop localitzat i corregit el defecte, quin procediment de prova aplicaries per certificar que l'error ha desaparegut per complet i no ha estat simple casualitat estadística?

La intranet del centre educatiu implementa un mòdul d'autenticació amb els requisits següents:

• Nom d'usuari: de 4 a 12 caràcters alfanumèrics, insensible a majúscules/minúscules.

• Contrasenya: entre 8 i 16 caràcters, sensible a majúscules/minúscules, amb almenys un dígit i un caràcter especial.

• Seguretat: bloqueig temporal del compte durant 15 minuts després de tres intents fallits consecutius.

Dissenya un pla de proves rigorós mitjançant una taula amb almenys sis casos de prova dissenyats per tu. Per a cada cas has d'especificar: identificador, valors d'entrada (usuari i contrasenya), estat previ del sistema, resultat esperat i quin risc específic de lògica, frontera o seguretat estàs validant.

Un programador sosté que «una funció d'una sola línia no necessita proves perquè és autoevident» i presenta aquesta funció escrita en C++:

bool esImpar(int n) {

    return (n % 2 == 1);

}

1. Prediu la sortida de la funció per a n = 7, n = 0 i n = -7. Explica tècnicament per què es produeix un resultat inesperat en un d'ells basant-te en com implementa l'operador mòdul (%) els operands negatius en aquest llenguatge.

2. Corregeix l'expressió perquè la funció sigui matemàticament correcta amb qualsevol nombre enter.

3. Recolzant-te en aquest cas, rebat amb dos arguments tècnics la idea de prescindir de proves unitàries en algorismes breus o aparentment trivials.

El sistema de supervisió d'un hivernacle s'ha programat en un únic fitxer dins d'una sola funció de 400 línies. El codi llegeix de manera seqüencial tres sensors analògics d'humitat de sòl, calcula la mitjana, avalua llindars, acciona una electrovàlvula mitjançant un pin digital, guarda el registre històric en un fitxer de text i envia un correu d'alerta si la humitat cau per sota del 30 %.

1. Justifica detalladament tres problemes tècnics greus que genera aquesta arquitectura quan es necessita depurar una fallada intermitent o realitzar proves unitàries automatitzades.

2. Dissenya una refactorització modular del programa: descompon la funció en almenys quatre funcions independents. Per a cadascuna defineix el seu nom, paràmetres d'entrada amb tipus, valor retornat i la seva responsabilitat única.

3. Explica com permetria el teu disseny provar l'algorisme de decisió de reg mitjançant simulació de dades, sense tenir els sensors físics connectats a la placa.

Un grup de tres estudiants desenvoluparà durant deu setmanes una aplicació de control d'assistència per al centre educatiu. Per evitar retards i lliuraments fallits d'última hora, has d'estructurar la metodologia de treball de l'equip:

1. Dissenya un cronograma organitzat en quatre fites o lliurables verificables, explicant quins criteris objectius s'han de complir abans d'autoritzar el pas a la fita següent.

2. Defineix un protocol formal de revisió per parells (code review): estableix qui revisa el codi de qui, quina llista de comprovació de qualitat mínima s'ha de superar abans d'acceptar qualsevol canvi i com es gestionen els desacords.

3. Estableix i justifica una política de «congelació de codi» (code freeze): en quina setmana s'ha d'activar, quin tipus de modificacions queden terminantment prohibides a partir d'aquell moment i quines tasques exclusives ha d'assumir l'equip fins al lliurament final.

Repte del tema. Com a analista júnior de programari, dissenyaràs un script en Python (pots utilitzar un entorn web gratuït com Replit) que avaluï el cost energètic diari per promoure l'estalvi domèstic.

Segueix aquestes tres fases:

1. Captura de dades: Entra al web de Red Eléctrica de España (REE) i registra el preu oficial ($€/\text{kWh}$) de $6$ franges horàries diferents del dia d'avui.

2. Disseny i codificació: Aplica el procés de desenvolupament de programari. Esbossa primer l'algorisme i trasllada'l a Python. El programa ha d'emmagatzemar les dades en una llista, utilitzar un bucle iteratiu per calcular el cost mitjà diari i emprar condicionals (if-else) que emetin alertes quan el preu superi el llindar de $0,18$ €/kWh.

3. Depuració i producte final: Fes proves amb valors límit i corregeix errors d'execució. Redacta un informe breu que inclogui el codi net i comentat, una captura del resultat a la consola i dues propostes de consum eficient per a la teva llar basades en les teves dades.

Es valorarà:

• Rigor en el procés de desenvolupament (disseny algorítmic previ, codificació textual i depuració).

• Ús correcte d'estructures de control (seqüencials, condicionals i iteratives) i sintaxi del llenguatge.

• Precisió en el tractament de dades reals i viabilitat de les conclusions energètiques.