Procés de desenvolupament de programari

De Viquipèdia
Salta a la navegació Salta a la cerca
Etapes del desenvolupament del programari

En l'enginyeria de programari, el procés de desenvolupament de programari (o cicle de vida del desenvolupament de programari) és una part del desenvolupament de programari. Es defineix com una seqüència d'activitats que han de ser seguides per un equip de desenvolupadors per generar o mantenir un conjunt coherent de productes.[1]

Es pot definir un procés com un marc de treball que ajuda el cap del projecte a controlar-ne la gestió i les activitats d'enginyeria. Això ajuda a establir el "qui fa què, quan i com" i un mecanisme de control per veure l'evolució del projecte.

Procés Unificat de Rational (RUP)[2][modifica]

El procés unificat de Rational (RUP) és un procés del desenvolupament de programari proposat per la companyia Rational Software el qual incorpora els coneixements anomenats best practices i està suportat per un conjunt d'eines, com el Llenguatge Unificat de Modelatge UML.

Els mètodes ofereixen tècniques de modelatge per les diferents etapes del procés de desenvolupament, incloent-hi anotacions especials, gràfics i criteris per desenvolupar programari de qualitat.

Les eines CASE (Computer Aided Software Engineering) ajuden a l'automatització de tot el procés de construcció del programari obtenint resultats d'alta qualitat.

Etapes del desenvolupament de programari[3][modifica]

Anàlisi de requisits[modifica]

L'objectiu principal d'aquesta etapa és obtenir el document d'especificació dels requisits. Aquest document se'l coneix com a especificació funcional. S'entén per especificació com la tasca d'escriure detalladament el programari a desenvolupar d'una forma matemàticament rigorosa. Aquestes especificacions es pacten amb els clients, els quals solen tenir una visió molt abstracta del resultat final, però no sobre les funcions que hauria de complir el programari.

L'anàlisi de requisits és regulat per la IEEE SA 830-1998,[4] document el qual conté pràctiques recomanades per a l'especificació dels requeriments del programari.

Disseny i arquitectura[modifica]

Aquesta etapa determina el funcionament general del programari sense entrar en detalls concrets sobre la seva implementació tècnica. També es tenen en consideració les implementacions tecnològiques necessàries com per exemple el maquinari i la xarxa.

Programació[modifica]

La complexitat i durada d'aquesta etapa depèn dels llenguatges de programació utilitzats, així com el disseny previ realitzat. Consisteix en la implementació

Un bon disseny inicial simplifica aquesta etapa. Mai s'hauria d'arribar a l'etapa de programació directament des del principi.

Proves[modifica]

En aquesta etapa els desenvolupadors de programari comproven que aquest funcioni de la manera esperada i especificada en les etapes anteriors. Aquesta és una etapa molt important doncs permet detectar errors de funcionament del programari abans de ser lliurat a l'usuari final. Es considera una bona pràctica que les proves les realitzin persones diferents dels desenvolupadors del programari.

Desplegament i manteniment[modifica]

El desplegament consisteix en l'entrega o posada en marxa del programari a l'usuari final. Es produeix un cop ha sigut degudament provat i avaluat.

El manteniment del programari consisteix en la correcció, millora i optimització d'aquest després del seu lliurament final a l'usuari. Això pot comportar la inclusió de codi addicional que no s'ajusta al disseny original per tal de solucionar un problema o ampliar la funcionalitat del programari al client final.

Podem distingir quatre tipus de manteniment de programari:

  • Perfectiu: millora la qualitat interna dels sistemes, com per exemple el codi font i l'optimització del rendiment.
  • Evolutiu: canvis que es realitzen en el programari per cobrir les noves necessitats de l'usuari.
  • Adaptatiu: són les modificacions que afecten els entorns on el sistema opera, com el sistema operatiu i les bases de dades.
  • Correctiu: són els canvis realitzats per solucionar errors de programari que no s'han pogut detectar a la fase de proves, o bé errors que s'han generat durant l'addició de noves característiques en el manteniment.

Models de desenvolupament de programari[modifica]

Els models de desenvolupament de programari són una representació abstracta que han estat utilitzats des dels orígens de la tecnologia de la informació.

Poden ser adaptats i modificats segons les necessitats del programari durant el procés de desenvolupament.

Podem diferenciar els models de desenvolupament de programari en 3 tipus:

Model en cascada[5][modifica]

També conegut com a model tradicional, s'anomena "en cascada" per la posició de les fases de desenvolupament en aquesta, que fan la impressió que cauen com si fossin un salt d'aigua (cap avall). 

Les diferents fases són:

  1. Anàlisi Especificació de requisits
  2. Disseny del programari
  3. Construcció o Implementació del programari
  4. Fase de Proves 
  5. Integració  
  6. Instal·lació 
  7. Manteniment

Les fases tenen un curs de forma estricta, és a dir, fins que no ha acabat una fase, no "baixa" a la següent. Fins i tot es pot realitzar una revisió abans de començar la següent fase, cosa que obre a la possibilitat de canvis, a més d'assegurar-te que la fase s'ha executat correctament.

Aquest control és un dels avantatges més destacades d'aquest model, en el que també s'inclou la minimització de les despeses en la planificació del projecte.

En canvi els desavantatges que s'hi troben a part de ser un flux seqüencial són que no involucren a l'usuari en el desenvolupament del projecte i es requereix molt de temps per al seu desenvolupament. També si l'usuari oblida especificar algun requeriment, el cost pot ser molt elevat. 

Model de prototip[6][modifica]

Model de prototip

El model de prototip de programari consisteix en la construcció d'aplicacions(prototips incomplets) que mostren la funcionalitat del producte mentre està en desenvolupament, tenint en compte que el resultat final pot no seguir la lògica del programari original.

Permet donar a conèixer al client els requeriments del programari en les primeres fases del procés de desenvolupament. També ajuda els desenvolupadors a entendre que s'espera exactament del producte en fase de desenvolupament.

Les fases de desenvolupament del model de prototip de programari són:

  • Identificació dels requeriments bàsics. Entendre les bases del producte en terme d'interfície d'usuari.
  • Desenvolupar el prototip inicial.
  • Anàlisi del prototip. El prototip és presentat al client, es recullen les opinions de manera organitzada per a futurs canvis.
  • Revisió i millora del prototip. Amb les opinions aconseguides, es discuteixen les possibles millores al prototip original.

Model de desenvolupament incremental[modifica]

Exemple de tasques en un model incremental

El model de desenvolupament incremental consisteix a anar incrementant el contingut del model fase per fase (disseny, implementació i fase de proves) constantment fins a acabar el programari. Inclou tant el desenvolupament del producte com el seu posterior manteniment.

Les claus són:

  • El model aplica diferents petits models salt d'aigua, on totes les fases d'un salt d'aigua formen part d'una petita part del sistema.
  • Com que aplica models salt d'aigua, després de cada iteració es pot fer una revisió per comprovar que tot ha anat correctament, i es pot canviar les errades que s'hi poden haver trobat.
  • El client pot respondre als canvis i analitzar constantment el producte per a possibles canvis.
  • L'enviament del producte inicial és més ràpid i pot ser més barat, però el producte resultant pot ser molt més car del previst.
  • Mentre es va progressant, poden aparèixer problemes d'estructura no presents en prototips de fases anteriors.

Model de desenvolupament iteratiu i incremental[modifica]

Model obtingut de combinar el model iteratiu amb el model de desenvolupament incremental. La relació entre ells dos ve determinada per la metodologia de desenvolupament i el procés de construcció del programari.

Facilita el procés de detecció d'errors i problemes importants abans que es manifestin i puguin causar un desastre (gràcies al model iteratiu, permet el backtracking).

Model espiral[modifica]

Model en espiral

Les activitats d'aquest model es conformen en una espiral, en la qual cada bucle o iteració representa un conjunt d'activitats. Aquestes activitats se seleccionen segons el factor de risc que representen, començant pel bucle anterior.

Es combinen aspectes claus del model de cascada i el model ràpid d'aplicacions per intentar aprofitar els avantatges que aporten els dos models.

Els principis bàsics d'aquest model són:

  1. El model se centra en l'avaluació del risc que es produeix i en la minimització del risc partint el projecte en diferents segments més petits i proveint facilitat de canvis en el procés de desenvolupament.
  2. Cada cicle consta d'una progressió per la mateixa seqüència de passos, per cada part del producte i per cada un dels seus nivells d'elaboració.
  3. Cada viatge per l'espiral travessa quatre quadrants:
    1. Determinació d'objectius
    2. Identificació i resolució de riscos
    3. Desenvolupament i proves
    4. Planificar la següent iteració
  4. Cada cicle comença amb una identificació de les seves condicions de victòria.

El risc identificat en cada procés determina el nivell d'esforç i el grau de detall del desenvolupament del programari.

Model ràpid d'aplicacions[modifica]

El model de desenvolupament ràpid d'aplicacions (Rapid application development - RAD) combina el desenvolupament iteratiu amb la ràpida construcció de prototips en comptes de planificacions a llarg termini. La falta d'aquesta planificació normalment permet que s'escrigui molt més ràpidament el programari, i fa més fàcil el canvi de requeriments.

El procés de desenvolupament ràpid comença amb el desenvolupament de models de dades preliminars i la utilització de tècniques estructurades per als models de processament. A la següent fase, els requeriments són verificats mitjançant prototips. Aquestes fases es repeteixen de manera iterativa.

Els principis bàsics són:

  • L'objectiu clau és el desenvolupament ràpid i l'enviament d'un sistema d'alta qualitat al menor preu possible
  • Intenta reduir el risc que conté el projecte trencant-lo en segments més petits i proveir facilitats de canvis durant el procés de desenvolupament.
  • Apunta a produir un sistema d'alta qualitat, principalment amb la creació de prototips, alta activitat dels usuaris i utilització d'eines de desenvolupament computades.
  • Involucrament actiu de l'usuari és imperativa .
  • Produeix programari de producció iterativa, al contrari d'un prototip de llançament.
  • Produeix informació necessària per a facilitar futurs desenvolupaments i manteniments.
  • El control del projecte es basa a prioritzar el desenvolupament i controlar les dates d'entrega del projecte (deadlines). Si un projecte comença a retardar-se, la prioritat es basa a reduir els requeriments perquè entri dins els terminis d'entrega i no en fer augmentar la data d'entrega final.
  • Els avantatges són el control de riscos, la millor qualitat i la relació entrega-cost-qualitat (entregar el projecte dins els terminis al menor cost possible mantenint la qualitat).
  • Els desavantatges són el risc a una nova aproximació, requeriment de temps per a la recol·lecció de recursos, menys control general, disseny pobre i llargs sistemes.

Model de desenvolupament àgil[modifica]

Amb "model de desenvolupament àgil" ens referim a un grup de metodologies de desenvolupament programari basades en el desenvolupament iteratiu, on requeriments i solucions evolucionen via col·laboracions entre equips organitzats.

S'utilitza el desenvolupament iteratiu com a base per a advocar un punt de vista més lleuger i centrat en les persones que en el cas de les solucions tradicionals. Els processos àgils utilitzen retroalimentació en comptes de planificació com a principal mecanisme de control. Aquesta retroalimentació es canalitza per mitjà de proves periòdiques i versions freqüents del programari.

Codificació i correcció[modifica]

La idea del model de codificació i correcció és crear immediatament un codi i, en cert punt, començar a provar-lo per detectar els errors inevitables que hi haurà abans de l'entrega final del programari.

Aquest model no és tant una estratègia com les que hem conegut fins ara, si no es podria definir com una solució a causa de falta d'experiència o pressió sobre els desenvolupadors quan es van acostant a una data d'entrega.

Aquest procés de codificar sense pla se'l coneix també com a cowboy coding.

Model orientat a la reutilització[modifica]

El model orientat a la reutilització s'aprofita de parts ja existents en altres programaris per a poder completar-se. Utilitza parts com l'ús d'actius de programari en les especificacions d'anàlisis, dissenys, implementacions i proves d'una aplicació o disseny de programari.

La reutilització té certs indicadors com:

  • Entre el 40% i 60% d'una aplicació és re-utilitzable en una altra.
  • Aproximadament el 60% d'una aplicació administrativa és re-utilitzable.
  • Aproximadament el 75% de les funcions són comuns a més d'un programa.
  • Només el 15% del codi trobat en molts sistemes és únic i nou a una aplicació específica.

Models de millora de processos[modifica]

ISO/IEC 12207[modifica]

És un estàndard internacional que descriu el mètode per a seleccionar, implementar i monitorar el cicle de vida per al programari.

Integració de Models de Maduresa de Capacitats (Capability Maturity Model Integration)[modifica]

És un dels models líders basats en millors pràctiques. Són avaluacions independents les que confirmen el grau amb el qual una organització segueix els seus propis processos, que no avalua la qualitat dels processos o del programari que es produeix. Aquest model té un àmbit global i no només està destinat al desenvolupament del programari.

ISO 9000[modifica]

Descriu uns estàndards per a un procés formalment organitzat amb la intenció de manufacturar un producte i els mètodes de comandament i monitoratge del progrés. Tot i que aquest estàndard va ser creat originalment per al sector de la manufacturació, els estàndards ISO 9000 s'han aplicat al desenvolupament de programari també. Com el CMMI, no garanteix la qualitat del resultat final, només que s'han seguit els processos formals d'empresa.

ISO/IEC 15504[modifica]

També conegut com a Software Process Improvement Capability Determination (SPICE), determina la capacitat de millora del procés de programari. Aquest estàndard té com a objectiu un model clar per a poder comparar processos. SPICE s'utilitza com en el CMMI. Modela processos per gestionar, controlar, guia i monitorar el desenvolupament del programari. Aquest model s'utilitza per mesurar el que una organització o projecte fa durant el desenvolupament del programari. Aquesta informació ajuda a identificar punts dèbils i definir accions per a fer els canvis de millora. També identifica punts forts que poden adoptar-se a la resta de l'organització.

Metodologia de sistemes lleugers (Soft Systems Methodology)[modifica]

Mètode general per a la millora de processos de gestió, serveix per abordar situacions problemàtiques en sistemes amb problemes lleugers.

Enginyeria del mètode[modifica]

En el camp de la informació de sistemes, és la disciplina per a construir nous mètodes de mètodes ja existents. Se centra en el disseny, construcció i avaluació dels mètodes, tècniques i eines de suport per al desenvolupament de sistemes d'informació. Millora la informació rebuda dels processos del sistema.

Mètodes Formals[modifica]

Els mètodes formals són solucions matemàtiques per a resoldre problemes de software i hardware quant a requisits, especificació i disseny. Exemples de mètodes formals inclouen el Mètode B, la xarxa de Petri, la demostració automàtica de teoremes, RAISE i el VDM. Hi ha diverses notacions d'especificacions formals, tals com el llenguatge Z. Més generalment, es pot utilitzar la teoria d'autòmates per a augmentar i validar el comportament de l'aplicació dissenyant un sistema d'autòmat finit.

Les metodologies basades en els autòmats finits permeten l'especificació de programari executable i evitar la creació convencional de codi.

Els mètodes formals es poden aplicar en programari d'aviació, especialment si és de seguretat crítica. Els estàndards d'assegurament del programari de seguretat, tals com D0178B demanen mètodes formals en el nivell més alt de categorització (Nivell A).

La formalització del desenvolupament de programari està guanyant força a poc a poc, en altres àmbits, amb l'aplicació del llenguatge d'especificació OCL2.0 (i especialitzacions tals com Java Modeling Language) i particularment amb Model-driven Architecture, que permet l'execució de dissenys, fins i tot especificacions.

Una altra tendència que està sorgint en el desenvolupament del programari és la redacció d'especificacions en algun tius de lògica, per a tot seguit executar aquella lògica com si es tractés d'un programa. El llenguatge OWL, basat en lògica descriptiva, n'és un bon exemple. També s'està treballant a enllaçar un idioma natural de forma automàtica amb lògica, lògica que pot executar-se.

Referències[modifica]

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Procés de desenvolupament de programari
  1. «Proceso de desarrollo de aplicaciones software» (en castellà). [Consulta: 4 octubre 2015].
  2. «Rational Unified Process - Best Practices for Software Development Teams» (en anglès). [Consulta: 4 octubre 2015].
  3. «El Proceso de Desarrollo de Software» (en castellà). [Consulta: 4 octubre 2015].
  4. «830-1998 - IEEE Recommended Practice for Software Requirements Specifications» (en anglès). [Consulta: 4 octubre 2015].
  5. «Ingeniería del Software - Modelos de Desarrollo» (en castellà). [Consulta: 14 octubre 2015].
  6. «Prototyping Model» (en anglès). [Consulta: 15 octubre 2015].