Model de desenvolupament iteratiu i incremental
El model de desenvolupament iteratiu i incremental és qualsevol combinació d'ambdós disseny iteratiu o mètode iteratiu i el model de generació incremental per al desenvolupament. La combinació és de llarga data[1] i ha estat àmpliament suggerit per als esforços de desenvolupament de grans dimensions. Per exemple, el 1985 DOD-STD-2167[2] esmenta (a la secció 4.1.2): "Durant el desenvolupament de programari, més d'una iteració del cicle de desenvolupament de programari pot estar en curs a la vegada. " i "Aquest procés pot ser descrit com una adquisició evolutiva o enfocament de generació incremental. "La relació entre iteracions i increments es determina pel procés general de desenvolupament de la metodologia de desenvolupament de programari i el programari. El nombre exacte i la naturalesa de l'increment concret construeix i el que es va reiterar seran específics per a cada esforç de desenvolupament individual.
El desenvolupament iteratiu i incremental són parts essencials dels models de cascada modificats, Rational Unified Process, Programació Extrema i en general els diversos marcs de desenvolupament de programari àgil.[3]
Descripció[modifica]
La idea bàsica darrere d'aquest mètode és desenvolupar un sistema a través de cicles repetits (iteratius) i en porcions més petites alhora (incremental), permetent als desenvolupadors de programari per prendre avantatge del que s'ha après durant el desenvolupament de les parts o versions anteriors del sistema. L'aprenentatge ve de tant el desenvolupament i l'ús del sistema, on els possibles passos clau en el procés comencen amb una implementació simple d'un subconjunt dels requisits de programari i de forma iterativa milloren les versions en evolució fins que s'implementi el sistema complet. A cada iteració, es fan modificacions de disseny i s'afegeixen noves capacitats funcionals.
El procediment en si consisteix en el pas d'inicialització, el pas de la iteració, i la Llista de Control del Projecte. El pas d'inicialització crea una versió bàsica del sistema. L'objectiu d'aquesta implementació inicial és crear un producte al qual l'usuari pot reaccionar. Ha d'oferir una mostra dels aspectes clau del problema i oferir una solució prou simple per entendre i implementar fàcilment. Per guiar el procés d'iteració, es crea una llista de control de projecte que conté un registre de totes les tasques que cal realitzar. Inclou elements com noves característiques per ser implementada i àrees de redisseny de la solució existent. La llista de control es revisa constantment com a resultat de la fase d'anàlisi.
La iteració implica que el redisseny i implementació d'iteració ha de ser simple, directe, i modular, recolzant redisseny en aquesta etapa o com una tasca afegida a la llista de control del projecte. El nivell de detall de disseny no està dictat per l'enfocament iteratiu. En un projecte iteratiu de pes lleuger el codi pot representar la principal font de documentació del sistema; no obstant això, en un projecte iteratiu crític pot ser utilitzat un Document de Disseny de Programari formal. L'anàlisi d'una iteració es basa en comentaris dels usuaris i les instal·lacions d'anàlisi de programa disponible. Es tracta d'una anàlisi de l'estructura, modularitat, facilitat d'ús, la fiabilitat, l'eficiència i l'assoliment de metes. La llista de control de projecte es modifica amb resultats de l'anàlisi obtingudes.
Fases[modifica]
El desenvolupament incremental divideix la funcionalitat del sistema en increments (porcions). A cada increment, una part de la funcionalitat es lliura a través del treball interdisciplinari, des dels requisits fins a la implantació. Els increments dels grups de processos unificats/iteracions en fases: creació, elaboració, construcció i transició.
- La creació identifica l'abast del projecte, els requisits (funcionals i no funcionals) i els riscos a un nivell alt, però en suficient detall perquè el treball es pugui estimar.
- L'elaboració ofereix una arquitectura de treball que mitiga els riscos principals i compleix amb els requisits no funcionals.
- La construcció emplena de forma incremental l'arquitectura amb codi llest per a la producció generada a partir de l'anàlisi, el disseny, la implementació i les proves dels requisits funcionals.
- La transició és la que ens ofereix el sistema en l'entorn operatiu de producció.
Cadascuna de les fases es poden dividir en una o més iteracions, que solen està dividides en sessions (temps o hores de dedicació). Els arquitectes i analistes treballen les iteracions per davant dels desenvolupadors i provadors per tal de poder mantenir la seva cartera de comandes del producte i no acumular feina.
Ús[modifica]
Molts exemples d'ús d'hora es proporcionen en l'article de Craig Larman i Victor Basili "Desenvolupament iteratiu i incremental: Una breu història", amb Projecte Mercury de la NASA dels anys 1960.[4]
Un altre és "un exemple ràpid sorprenent d'un important èxit de IID és el cor mateix del sistema de programari d'aviònica de la NASAel sistema de programmari del transbordador espacial primari que FSD va construir entre 1977 i 1980. L'equip va aplicar IID en una sèrie de 17 repeticions en 31 mesos, amb una mitjana al voltant de vuit setmanes a iteració. seva motivació per evitar el cicle de vida cascada va ser que els requisits del programa de transport canvien durant el procés de desenvolupament de programari".
Algunes organitzacions, com el Departament de Defensa dels Estats Units, tenen una preferència per mètodes iteratius, començant amb la norma MIL-STD-498 "encoratjar clarament adquisició evolutiva i IID".
L'actual Instrucció DoD 5000.2, llançada en 2000, estableix una clara preferència per IID: "Hi ha dos enfocaments, pas evolutiu i pas únic [cascada], per emplenar capacitat. Es prefereix un enfocament evolutiu. ... [En aquesta] enfocament, la capacitat final lliurada a l'usuari es divideix en dos o més blocs, amb l'augment d'increments de capacitat ... el desenvolupament de programari ha de seguir un procés de desenvolupament en espiral iteratiu en el qual les versions de programari en contínua expansió es basen en l'aprenentatge de desenvolupament anterior. També es pot fer en fases.
Contrast amb desenvolupament de la cascada[modifica]
El desenvolupament de la cascada completa els productes de treball de tot el projecte de cada disciplina en un sol pas abans de passar a la següent disciplina en el següent pas. El valor del negoci es lliura una sola vegada, i només al final del projecte. Backtracking és possible en un enfocament iteratiu.
Directrius d'aplicació[modifica]
Directrius que impulsen la implementació i l'anàlisi inclouen:
- Qualsevol dificultat en el disseny, codificació i proves d'una modificació ha d'assenyalar la necessitat de redisseny o re-codificació.
- Les modificacions han de cabre fàcilment en mòduls aïllats i fàcils de trobar. Si no ho fan, és possiblement necessari una mica de redisseny.
- Les modificacions a les taules han de ser especialment fàcils de fer. Si alguna modificació de taula no es realitza de forma ràpida i senzilla, redisseny s'indica.
- Les modificacions han de ser més fàcils de fer que el progrés iteracions. Si no és així, hi ha un problema bàsic tal com un defecte de disseny.
- La implementació existent ha de ser analitzada amb freqüència per determinar el bé que a l'altura dels objectius del projecte.
- Instal·lacions d'anàlisi de programa s'han d'utilitzar sempre que estiguin disponibles per ajudar en l'anàlisi d'implementacions parcials.
- Reacció de l'usuari ha de ser sol·licitada i analitzada per indicis de deficiències en la implementació actual.
Referències[modifica]
- ↑ Cockburn, Alistair. Using Both Incremental and Iterative Development, maig de 2008 [Consulta: 21 octubre 2014]. Arxivat 2012-05-26 a Wayback Machine.
- ↑ Larman, Craig; Basili, Victor R. Iterative and Incremental Development: A Brief History, juny de 2003.
- ↑ ; Trejo Omeñaca, Alex Innovació guiada pel disseny. Universitat Politecnica de Catalunya, 2019, p. 89. ISBN 9788498808193.
- ↑ Craig Larman, Victor R. Basili «Iterative and Incremental Development: A Brief History». Computer. IEEE, juny 2003, pàg. 46-56 [Consulta: 22 desembre 2023].