|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Enginyeria del programariJoan Puigcerver Ibáñez Llicència: CC BY-NC-SA 4.0 (Reconeixement - NoComercial - CompartirIgual) 🅭 
Enginyeria del programari¶Desenvolupar programari implica moltes persones amb punts de vista diferents sobre el mateix projecte (Figura 1). L'enginyeria del programari naix precisament per posar ordre en aquest procés.
Autoria desconeguda Figura 1. Diferents punts de vista del desenvolupament de programari. Què és l'enginyeria del programari?¶L'enginyeria del programari és una disciplina que engloba ferramentes, tècniques, recomanacions i mètodes que s'utilitzen en la creació d'una aplicació, un sistema o una plataforma informàtica o, de manera més general, en el desenvolupament d'un projecte de programari que resol un problema o cobreix una necessitat.
Aquesta disciplina té la codificació com a pilar fonamental, però inclou altres tasques, abans i després, que són tant o més importants. Per tant, l'enginyeria del programari s'encarrega de tota la gestió del projecte perquè es puga desenvolupar en temps i forma, és a dir, en el termini determinat i amb el pressupost i els requisits previstos. L'enginyeria del programari inclou les tasques següents:
Per què és important?¶El terme crisi del programari es va encunyar a principis dels anys 70, quan la planificació d'un projecte de programari era pràcticament inexistent. Es seguia un procés de desenvolupament força artesanal, sense una metodologia ni un camí definit. L'anàlisi prèvia a la codificació ocupava el 8 % del temps total de desenvolupament. No obstant això, el 80 % dels errors es produïen en aquesta fase, i el cost de corregir-los augmentava a mesura que avançava el projecte. Amb aquests indicadors, era evident que alguna cosa fallava i que el procés de desenvolupament de programari necessitava un canvi radical. L'Informe CHAOS de l'Standish Group sobre l'èxit dels projectes de programari va concloure el 2015 que (Figura 2):
Cada any, des del 1994, l'Standish Group elabora una llista de 10 atributs, amb el seu pes relatiu, que anomena factors d'èxit. Els tres primers per al 2018 són:
Standish Group 2015 Chaos Report Figura 2. Estadístiques de l'informe CHAOS 2015. Cicle de vida del programari¶Fases més comunes¶Les fases del desenvolupament de programari, conegudes com a cicle de vida del programari, representen les etapes per les quals ha de passar una aplicació per ser lliurada amb totes les garanties (Figura 3).
Autoria desconeguda Figura 3. Cicle de vida del programari. Per a cada fase, s'indica què es fa, quins perfils professionals hi participen i què es genera. Anàlisi¶
L'anàlisi d'una aplicació pretén determinar les necessitats que ha de cobrir. Aquesta fase es realitza en contacte directe amb el client i s'hi especifiquen els requisits funcionals i no funcionals del projecte. Els requisits obtinguts es plasmen en aquests documents:
Els requisits s'agrupen en:
Disseny¶
En el disseny (o modelatge del programari) es planteja una solució per a l'aplicació i se'n fa un model amb diferents tècniques. Aquest disseny sol fer-se per nivells: es comença amb una idea general que es divideix en components per modelar després cadascun (disseny descendent o top-down). No s'ha de confondre la fase de disseny de l'enginyeria del programari amb el disseny gràfic (l'aspecte de l'aplicació). Codificació¶
En la codificació s'implementa el programa amb tots els seus components, inclosos elements com la base de dades, els servidors o les comunicacions. En molts projectes es comet l'error de suposar, d'una banda, que qui programa és la persona per a tot en el desenvolupament del programari i, d'altra banda, que qualsevol analista o consultor també programa bé. A més, no tots els perfils professionals estan capacitats per tractar directament amb el client. Proves¶
Les proves són revisions que han de fer persones diferents de les que han codificat l'aplicació, per detectar errors d'usabilitat o errors no detectats en la fase anterior. Es poden fer proves de diversos tipus: unitàries, d'integració i, sobretot, d'acceptació amb el client, sempre amb l'especificació de requisits de l'anàlisi com a referència. Documentació¶
La fase de documentació consisteix a deixar per escrit les decisions tècniques que s'han pres: des de per què s'ha triat un framework i no un altre fins a per què s'han creat 10 taules en la base de dades i no 200. Aquesta fase no s'ha de fer necessàriament després de la codificació. De fet, es considera una bona pràctica documentar alhora que es codifica. Implantació o desplegament¶
La implantació o desplegament consisteix a publicar la solució final en la plataforma de destinació o lliurar al client el producte final en el format acordat. No s'ha de confondre la implantació amb la implementació (la codificació). Molt poques persones de l'organització tenen (o han de tindre) accés als servidors on s'allotgen les aplicacions publicades (servidors de producció). Per això, aquesta fase recau en els perfils més veterans i experimentats (sènior). Manteniment¶
La fase de manteniment sol tindre una secció específica en els contractes de desenvolupament, on es detalla com es facturarà aquest servei i en quins termes. El manteniment pot ser:
En aquest punt, el programari ja està lliurat i facturat, per la qual cosa se sol restar importància al manteniment. No obstant això, moltes empreses de desenvolupament de programari paguen gran part de les nòmines de la plantilla amb les quotes de manteniment dels clients. Aquesta fase sol recaure en les persones nouvingudes (júnior). Tipus de cicles de vida¶Segons com s'ordenen les fases anteriors, hi ha diferents tipus de cicles de vida. Clàssic o en cascada (waterfall)¶En el model en cascada, totes les fases es distribueixen en una estructura lineal, sense retroalimentació ni possibilitat de tornar enrere (Figura 4). Per això, només és vàlid en projectes grans amb requisits molt clars.
Autoria desconeguda Figura 4. Model en cascada. Cicle de vida iteratiu¶En el model iteratiu, totes les fases es distribueixen en una estructura que repeteix en bucle el cicle lineal (Figura 5). Una vegada desplegada l'aplicació, es prova i s'avalua el sistema per vore si cal fer alguna modificació.
Autoria desconeguda Figura 5. Model iteratiu. Cicle de vida en espiral¶El model en espiral parteix del model iteratiu i hi afig la gestió de riscos, per determinar si és viable continuar o aturar el desenvolupament de l'aplicació (Figura 6).
Autoria desconeguda Figura 6. Model en espiral. Metodologies¶Els cicles de vida es combinen i s'adapten per crear metodologies, que ofereixen tècniques concretes per a cada etapa o fase dels cicles de vida escollits. Hi ha dos enfocaments principals:
Segons l'informe CHAOS, els projectes amb metodologies àgils tenen més èxit que els que segueixen el model en cascada (Figura 7).
Standish Group 2015 Chaos Report Figura 7. Estadístiques de l'informe CHAOS: metodologies àgils vs. cascada. Bibliografia¶
📌 Aquest document pot quedar desactualitzat després d’imprimir-lo. Pots consultar la versió més recent
a la pàgina web.
🌿 Abans d’imprimir aquest document, considera si és realment necessari. Redueix el consum de paper i ajuda a protegir el nostre entorn.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
