Enginyeria de requisits
Enviado por Xavi Ortega • 8 de Enero de 2023 • Apuntes • 11.348 Palabras (46 Páginas) • 275 Visitas
Enginyeria del software iii
[pic 1]
Teoria
Continguts
Enginyeria de requisits 3
Stakeholders 3
Tipus de stakeholders 3
Flux de requisits 5
Com han de ser els requisits 7
Enginyeria de requisits 9
Split test 10
MVP 11
Innovation accounting 11
Desenvolupament metodologies àgils 12
Introducció a “agile” 12
Avantatges de les metodologies àgils 14
Desenvolupament a les metodologies àgils 15
Manifest agile 16
24/04/2019 18
Requisits 18
Refactor i testing 19
Codi de producció i codi de test 20
Test-driven development 21
Enginyeria de requisits
Consisteix a saber identificar el problema amb què tractarem (què cal fer, quins detalls són importants i quins no…). Cal comprendre què es necessita a l’empresa per resoldre un aspecte determinat del seu negoci.
L’enginyeria de requisits consta de dues parts, d’una banda cal entendre el problema i d’altra banda, s’ha de construir la solució. Habitualment, la solució que proposarem serà un software.
La definició del problema en sí mateixa pot no especificar directament qüestions que a la pràctica s’hauran de tenir en compte, que se’n poden derivar de forma implícita (poden sortir a la llum detalls més complexos que caldrà implementar, etc).
Stakeholders
Per identificar el problema primer cal ser capaç d’identificar a aquells actors que ens puguin donar informació, o stakeholders. Els stakeholders són persones que estan al voltant de l’empresa o del problema, que ens poden proporcionar informació sobre com solucionar-lo o com treballar-hi. Es poden entrevistar, preguntar… De vegades no es té accés a ells directament però se’n pot extreure informació d’alguna altra manera.
Tipus de stakeholders
Podem dir que hi ha dues classes de stakeholders:
- Interns: Són a dins del negoci i els que hi estan més implicats (tots els stakeholders són necessaris perquè l’empresa prosperi, però els interns tenen major interès en què el negoci funcioni).
Són els empleats (font d’informació més gran, cal tenir-los especialment presents com a principal punt d’innovació), managers, propietaris (en el sentit de propietari del negoci, d’una S.L, no d’accionista).
- Externs: són accionistes (propietaris d’una empresa S.A), clients (d’entre els externs són els que tenen major importància com a font d’informació, se’ls podria llistar en primer lloc), proveïdors, societat, i govern.
Quan es fa l’anàlisi de requeriments, habitualment parlarem primer amb el manager, qui ens donarà una sèrie de requisits que després haurem d’intentar reconcil·liar amb les necessitats dels empleats. S’ha de valorar que els empleats tenen informació del funcionament del dia a dia del negoci de primera mà, i que les seves experiències, expectatives i desitjos no tenen perquè coincidir amb els del manager.
Els clients són els usuaris del servei. Poden aportar informació, requeriments, etc. que seria impossible obtenir a partir dels stakeholders interns. Gràcies a ells, podem donar explicació als problemes que hagin percebut els stakeholders interns, ja que es pot saber un comportament dels usuaris però no comprendre a què respon.
Per exemple, en el cas de la biblioteca els stakeholders interns poden saber que hi ha un tant per cent de tornada de llibres massa baix i que això s’ha de solucionar, però no saber a què és deguda aquesta conducta.
Preguntant als usuaris, podem esbrinar per què es dóna aquesta situació i proposar la solució més adient (si el problema fos que l’horari de la biblioteca és poc convenient per als usuaris, es podria pensar fer servir una bústia per deixar llibres que estigués operativa 24 hores).
A aquesta solució podria no arribar-s’hi si no fos per la informació dels usuaris (els treballadors, gerents, etc. no pensarien a demanar una bústia per ells mateixos, tenint en compte que els hi pot aportar un increment de feina, que poden sorgir preocupacions per la possible pèrdua o substracció dels llibres… D’aquesta manera, és la necessitat de l’usuari el què realment justifica l’implementació d’aquesta mesura).
Som enginyers de software, però això no vol dir que ens haguem de limitar a solucions software. El software viu dins de l’entorn d’una organització, i poden ser necessaris canvis més amplis dins d’aquest (per exemple, podriem fer la proposta de posar una bústia de llibres electrònica, que tindria un suport software elaborat per nosaltres).
Els proveïdors també poden donar feedback útil, sobretot en cas que hagin d’interactuar amb sistemes d’informació interns de l’empresa, aplicacions, o altre software d’aquesta.
Certes necessitats del software sorgeixen no només de les preferències del client, sinó de la pròpia societat, sobretot en temes d’usabilitat, accessibilitat,... Es pot veure amb un exemple tan senzill com que hi ha algunes paraules que no es poden fer servir perquè estan mal vistes.
Per últim, cal consultar la legalitat vigent, normativa de protecció de dades, etc. No podem fer les coses de qualsevol manera sinó que disposem d’aquestes normes que ens limiten les solucions que podrem considerar, ja que no podem infringir-les.
...