Enginyeria de requisits

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.