Model de prototips

De la Viquipèdia, l'enciclopèdia lliure

El model de prototips, és l'activitat de crear prototips d'aplicacions de programari des de zero o de versions incompletes de programari ja desenvolupat. Aquesta activitat de l'Enginyeria de programari es pot comparar amb la creació de prototips en altres camps com l'Enginyeria mecànica o la manufactura. Un prototip típicament simula pocs aspectes del producte final, i fins i tot pot ser completament diferent.

Els prototips tenen una gran quantitat de beneficis: El dissenyador de programari pot obtenir informació important dels primers usuaris del projecte. El client pot comparar si el programari fet, coincideix amb el de la seva especificació acordada per construir el projecte. També permet tenir una idea sobre les estimacions inicials del projecte i si els terminis proposats es podran complir amb èxit. El grau d'exhaustivitat i les tècniques utilitzades en la creació de prototips han estat en desenvolupament i en debat des de la seva proposta el 1970.[1]

Descripció[modifica]

L'objectiu d'un prototip és la de permetre als usuaris avaluar el projecte proposat pels desenvolupadors, i si és el cas, proposar-los requeriments que no han proposat. És una manera més fàcil per als desenvolupadors que no pas llegir un document amb tota la descripció del programa, i que pot ser un factor important en la relació comercial entre els desenvolupadors i els clients.[2] El disseny interactiu fa un ús intensiu del prototipatge amb aquesta finalitat.

El prototip també es pot utilitzar pel consumidor final per descriure i provar els requirements que no han sigut considerats, i que poden ser un factor clau en la relació comercial entre els dissenyadors i els clients.[3] El disseny d'interacció fa un gran ús del model de prototips.

Aquest model és diferent de l'utilitzat en els anys 1960 i 1970 on primer es construïa tot el programa i tot seguit es tractaven les incoherències entre el disseny i la implementació. Això comportava softwares més costos i unes estimacions de cost i de temps pobres. La pràctica del prototipat és un dels punts clau de Frederick Phillips Brooks, Jr en el seu llibre del 1975 anomenat The Mythical Man-Month i també en el seu article anomenat No Silver Bullet.

Un exemple a gran escala de prototips va ser la implementació del traductor NYU's Ada/ED pel llenguatge Ada (llenguatge de programació.) [4] Va ser implementat utilitzant el llenguatge SETL amb la intenció de produir un model semàntic executable pel llenguatge ADA, centrant-se més en la qualitat del disseny i la interfície d'usuari que no pas la velocitat i l'eficiència. El sistema NYU Ada/ED va ser la primera aplicació validada en llenguatge ADA, certificada l'11 d'abril de 1983.[5]

Esquema del procés de creació dels prototips [cal citació][modifica]

El procés de creació de prototips consta dels següents passos:

  1. Identificar els requisits bàsics, on es determinen les necessitats bàsiques, com la informació d'entrada i sortida. Els detalls, com per exemple la seguretat, poden ser ignorats.
  2. Desenvolupar el prototip inicial, on bàsicament només inclou la interfície d'usuari)
  3. Anàlisis, on els clients i usuaris finals examinen el prototip, i donen informació sobre els canvis o noves característiques.
  4. Revisió i millora del prototip, on fent servir la informació del client s'improvisa el prototip. Si es produeixen canvis en l'especificació, és possible que s'hagin de repetir els passos 3 i 4.

Esquema del cicle de vida d'un sistema [cal citació][modifica]

  1. Definició del projecte
    En aquesta etapa s'identifiquen els problemes, objectius i es determinen els requeriments de la informació de la manera més objectiva possible.
  2. Disseny
    Una vegada recopilada tota la informació s'elabora un disseny lógic del sistema d'informació. Llavors es realitzen les descripcions formals, que implica dissenyar procediments per l'obtenció de dades, interfície amb l'usuari, una base de dades eficient, etc.
  3. Programació
    Aquesta etapa es tradueix les especificacions del disseny en un codi de programació.
  4. Instal·lació
    Consisteix a provar el sistema i es fan les primeres avaluacions.
  5. Post-implementació
    En aquesta etapa s'avalua el sistema constantment després d'entrar en funcionament.

Dimensions dels prototips[modifica]

Dimensió del prototip

Les dimensions que té un prototip són les següents:[6]

Prototip horitzontal[modifica]

Proporciona una àmplia visió de tot un sistema, centrant-se més en la interacció de l'usuari en comptes de la funcionalitat del sistema a baix nivell, com per exemple l'accés a la base de dades. És especialment útil per a confirmar els requisits de la interfície d'usuari i la visió del sistema, per fer demostracions i obtenir més acceptació per part de les empreses, i finalment per fer estimacions preliminars del temps de desenvolupament, cost i esforç.

Prototip vertical[modifica]

És una elaboració molt més completa d'una funció o subsistema, especialment útil per a l'obtenció detallada de requisits d'una funció donada, on aporta els següents beneficis:

  • Refinament del disseny de la base de dades
  • Obtenir informació sobre volums de dades, les necessitats de la interfície del sistema, determinar la mida de la xarxa i l'enginyeria del rendiment
  • Aclarir els requisits complexos aprofundint en la funcionalitat real del sistema

Tipus de processos per la creació de prototips[modifica]

Els models de prototips tenen moltes variants. Tot i així, tots ells estan basats d'alguna manera amb en els dos tipus més importants: els Prototips d'un sol ús (Throwaway Prototyping) i els Prototips evolutius (Evolutionary prototyping).

Prototip d'un sol ús[modifica]

Es refereix a la creació d'un model que més endavant es descartarà en comptes d'utilitzar-se en una part final del model creat. El motiu més obvi d'aquest tipus és que es pot desenvolupar molt ràpidament, llavors els usuaris poden veure si s'ajusta a les seves necessitats, i es poden refinar els aspectes millorables en el seu desenvolupament. Fer canvis al principi del cicle del desenvolupament és molt rendible, ja que no s'ha de refer res, tot just estem començant.

Això és un punt fort d'aquest tipus, ja que si modifiquem el projecte després d'haver fet una gran quantitat de feina, aquests petits canvis poden ser molt complicats de posar en practica, a causa de la gran dependència que pot tenir el software. Guanyem molta rapidesa i estalviem recursos valuosos. Un altre punt fort és la capacitat de construir interfícies que els usuaris poden provar, i ja que és una de les parts essencials del projecte (perquè l'usuari fa servir la interfície per veure el sistema) podem conèixer les seves opinions.

Un prototip d'un sol ús es refereixen a la creació de un model que serà descartat de manera eventual en lloc d'esdevenir part del programari final. Després de reunir els requisits preliminars, es construeix un model de treball senzill, una interfície que els usuaris podran provar per veure si s'ajusta als requisits que volen que tingui el sistema final.

Com que aquest tipus de prototips es fan després duna investigació relativament curta i el seu objectiu és proporcionar als usuaris l'opció de tornar :a revisar les seves expectatives i aclarir els seus requisits, el mètode utilitzat en la seva construcció sol ser força informal, fent que la seva :part més important sigui la rapidesa de creació. Un cop aconseguit el seu objectiu, aquest prototip serà “llançat” i el sistema es desenvoluparà de :manera formal segons els requisits identificats.[3]

La raó obvia que justifica la utilització d'uns prototips que seran descartats és la rapidesa. Aplicar canvis al principi del cicle de vida del desenvolupament és molt rendible perquè no hi ha res que s'hagi de refer. Modificar un projecte després que s'hagi dut a terme una quantitat raonable de feina, pot provocar grans esforços d'implementació, ja que en l'enginyeria de programari existeixen moltes dependències i un petit canvi pot generar una cadena de modificacions que pot canviar tota l'estructura general del sistema. A més, la rapidesa també és imprescindible en els Prototips d'un sol ús pel que fa al seu propi desenvolupament, ja que no interessa dedicar molts temps i diners en la creació d'un prototip que serà descartat en un futur.

...És encertat afirmar que la creació de Prototips d'usar i llençar és la manera més eficaç per resoldre les qüestions relacionades amb les :necessitats dels usuaris, i per tant un major realç de la producció general de programari. Els requeriments poden ser identificats, simulats i provats de manera més ràpida i barata quan s'ignoren els problemes evolutius, el manteniment i l'estructura del programari. Això, al mateix temps, :dona lloc a l'especificació exacta de les necessitats i la posterior construcció d'un sistema bàsic i utilitzable en perspectiva de l'usuari per :mitjà dels models de prototips.[7]

Prototip evolutiu[modifica]

L'objectiu principal és la de construir un prototip molt robust d'una manera estructurada, constantment sota millores. El motiu d'aquest disseny és que a mesura que anem construint el prototip inicial, aquest serà el cor del nou sistema, i s'aniran construint millores i nous requisits a mesura que es vagi desenvolupant.

L'objectiu principal de la creació dels Prototips evolutius és crear un prototip molt robust de manera estructurada, constantment refinada i reconstruïda. Quan aquests prototips són construïts, es pretén que siguin el centre del nou sistema, i que a patir d'ell se li incorporin millores i nous requisits.

“... El Prototip evolutiu reconeix que no entenem tots els requisits i es basa només en aquells que s'entenen bé.”[8]

Aquesta tècnica permet a l'equip de desenvolupament agregar noves característiques, o fer canvis que no es podrien realitzar durant els requisits i la fase de disseny.

“Perquè un sistema sigui útil, te que ser capaç d'evolucionar a través del seu sistema operatiu previst. Un producte mai es “fa”, sempre esta :madurant com tal com el seu entorn d'ús canvia... Sovint tractem de definir un sistema utilitzant el nostre marc més familiar de referència d'on :estem ara. Fem suposicions sobre la forma en què es durant a terme els negocis i la seva base tecnològica. Un pla es promulgat per desenvolupar la :capacitat, i tard o d'hora, quelcom semblant al sistema final enllestit.”[9]

Aquests prototips, presenten un gran avantatge respecte als Prototips d'un sol ús, i és en que són sistemes funcionals. Encara que no tinguin totes les característiques que els usuaris han planificat, poden ser utilitzats de forma provisional fins que el sistema final s'enllesteix.

“No es estrany que en un entorn de creació de prototips l'usuari disposi d'un prototip per l'ús pràctic a l'espera d'una versió més desenvolupada... :L'usuari pot decidir que un sistema defectuós sigui millor que un sistema absolut.”[3]

En els Prototips evolutius, els desenvolupadors poden enfocar-se en parts del sistema que puguin comprendre en lloc de treballar en el desenvolupament de tot el sistema.

Per minimitzar el risc, els desenvolupadors no implementen les característiques poc conegudes. El sistema parcial s'envia a les instal·lacions del :client. Com que els usuaris treballen en el sistema, són capaços de detectar possibles noves característiques i enviar-l'hi sol·licituds sobre elles :als desenvolupadors. Després els desenvolupadors agafen aquestes sol·licituds de millora juntament amb les seves pròpies, i utilitzen pràctiques de :gestió per tal de canviar l'especificació dels requisits del programari, recodificar i tornar a provar.[10]

Prototip incremental[modifica]

El producte final es construeix "fusionant" prototips de manera separada. Normalment amb aquest model aconseguim reduir el temps entre els usuaris finals i els propis desenvolupadors del producte.

El producte final es construeix a partir de prototips separats, això permet la utilització parcial del producte, i per tant el client pot anar provant cada part del sistema sense tenir el sistema final, això fa que el client s'esperi menys a veure els resultats desenvolupats. Al final els prototips independents es fusionen en un disseny general. Aquest ús dels Prototips incrementals presenta certs avantatges i inconvenients:

Avantatges:[11][12]

  1. Es poden realitzar proves després de cada iteració. Durant les proves, els elements defectuosos es poden identificar ràpidament.
  2. Com que els canvis en cada iteració són petits, es poden realitzar proves més rigoroses i especifiques de cada element del sistema.
  3. El client pot respondre a les característiques i revisar el producte per qualsevol canvi necessari
  4. L'entrega del sistema final és més ràpida i més barata.

Inconvenients:[13]

  1. La gestió de les despeses, l'horari i la complexitat de la configuració, poden arribar a superar les capacitats de l'organització.
  2. Quan s'afegeixen noves funcionalitats al producte, poden aparèixer problemes relacionats amb l'arquitectura del sistema.

Prototip extrem[modifica]

Aquests prototips es desenvolupen en capes per mitjà d'aplicacions web. Bàsicament utilitza 3 fases, cada una basada en l'anterior:

  1. Crear un prototip que consisteix generalment en pàgines HTML.
  2. Les pantalles estan programades i són completament funcionals per mitjà d'una capa de serveis simulada.
  3. S'implementen els requisits.

El nom d'“extrem”, ve donat per la segona fase, on la interfície usuari és completament funcional sense importar els serveis que no requereixen el seu contracte.

Avantatges i inconvenients[modifica]

Avantatges[modifica]

Avantatges i inconvenients del prototip

Hi ha molts avantatges en l'ús del model de prototipatge, algunes més tangibles, algunes més abstractes.[14][15]

Temps i costos rebaixats: Els prototips poden millorar la qualitat de les especificacions i els requisits que proporcionen els desenvolupadors. A causa que els canvis cada vegada són més costosos en relació exponencial amb el temps, la detecció d'aquests en un prototip permet que l'usuari detecti ràpidament el que realment vol de manera menys costosa i més ràpida.[7]

Milloren i augmenten la participació dels usuaris: Els prototips requereixen la participació dels usuaris i els i permet veure i interactuar amb un prototip completament millorable.[3] La presència d'un prototip que l'usuari pugui examinar, pot evitar molts malentesos i errors de comunicació entre ells i els desenvolupadors. Com que són els usuaris els que tenen el problema, són els que tenen el major domini d'aquest, per tant la interacció entre ells i l'equip de desenvolupadors permet obtenir un producte final de més qualitat i que doni una millor solució al problema plantejat.

Inconvenients dels prototips[modifica]

L'ús, o el mal ús en el model de prototipatge també pot tenir desavantatges.

Anàlisi insuficient: L'ús del prototip pot distreure al desenvolupador envers el projecte complet. Això pot donar lloc a passar per alt millors solucions, un millor anàlisi del producte a desenvolupar o transformacions de prototips incomplets o ineficients en projectes finals difícils de mantenir. També pot passar que el prototip tingui una funcionalitat limitada, i si el prototip s'utilitza com a base d'un projecte final, pot donar-se que no evolucioni correctament perquè el desenvolupador està massa centrat en la construcció del prototip.

Confusió dels usuaris envers el prototip i el producte acabat: L'usuari final pot pensar que un prototip, que està destinat a ser una prova del projecte, sigui el producte final que ha de ser acabat o millorat, i no pas el projecte final que pugui entregar el desenvolupador. També pot donar lloc que els usuaris s'acostumin a unes característiques que estan incloses en el prototip, i que són absents en el producte final.

Confusió del desenvolupador sobre els objectius dels usuaris: El desenvolupador pot assumir que els usuaris comparteixen els seus objectius sense arribar a entendre els motius, com per exemple millorar algun camp o introduir millores d'algun tipus, sense que l'usuari digués que es necessités aquesta característica, i que poden exigir més memòria addicional o un hardware més potent.

També es pot donar que els usuaris exigeixin revisar tots els camps del projecte, de mentre que els desenvolupadors podrien pensar que això són suposicions sobre la magnitud de les necessitats dels usuaris. Si el desenvolupador s'ha permès la llibertat d'improvisar abans de fer un estudi sobre les necessitats dels usuaris, pot quedar en una posició molt desfavorable, sobretot si l'usuari li crida l'atenció en la seva falta d'anàlisi dels requisits.

Afecció del desenvolupador al prototip: El desenvolupador també pot arribar a tenir una afecció al prototip que li ha generat un gran esforç en produir. Això pot conduir a problemes com tractar de convertir un prototip limitat en un sistema final que no té una arquitectura apropiada. En aquest cas es podria deduir que s'ha utilitzat un tipus de prototip d'un sol ús, en comptes de fer servir el tipus de prototip evolutiu, que seria el més adient.

Temps de desenvolupament excessiu del prototip: Una condició molt important per a la creació del prototip s'ha de fer ràpidament. Si el desenvolupador perd de vista aquest fet, pot donar-se que tractin de desenvolupar un prototip massa complex. Quan el prototip es deixa d'utilitzar, els recursos invertits en aquest prototip poden no haver-se aprofitat com és degut, per tant no compensa el temps i recursos d'haver-lo fet. Els usuaris poden estancar-se en debats sobre els detalls del prototip, fent que el desenvolupador retardi el producte final.

Despeses d'implementar prototips: Els costos inicials per a la construcció d'un equip de desenvolupament centrat en la creació de prototips poden ser alts. Moltes empreses tenen les seves metodologies i maneres de treballar, les quals no els interessa canviar, ja que això provocaria retards, tornar a ensenyar als empleats o les dues coses. Normalment tendeixen a saltar la creació d'un prototip, sense molestar-se en reeducar els seus treballadors i treure'n el màxim rendiment.

Un problema comú alhora d'utilitzar la tecnologia de prototipat :són les altes expectatives de productivitat amb un esforç :insuficient. A més hi ha una necessitat que se sol passar per :alt, el desenvolupament d'una corporativa de desenvolupament i un :projecte específic subjacent a l'estructura per donar suport a la :tecnologia. Quan s'omet aquesta estructura subjacent, porta a una :reducció de la productivitat.[16]

Millors projectes per l'ús de prototips[modifica]

El màxim benefici de la utilització de prototips s'obté en els sistemes que tenen moltes interaccions amb els usuaris.

S'ha demostrat que el model de prototips és molt efectiu en l'anàlisi i disseny de sistemes on-line, especialment pel processament de transaccions. Com més gran és la interacció entre l'usuari i l'ordinador, més gran serà el benefici que es podrà obtenir de construir un sistema ràpid.[3]

Els sistemes amb poca interacció amb els usuaris com batch processing o sistemes que es dediquen només a fer càlculs no tenen gaire beneficis de l'ús de prototips. El prototips és especialment útil per dissenyar bones interfícies humà-ordinador. "Un dels usos més productius dels prototips ha estat com a eina pel disseny d'interfícies huma-ordinador.[7]

Mètode de desenvolupament de sistemes dinàmics[modifica]

El mètode de desenvolupament de sistemes dinàmics[17] (DSDM) és un mètode que proveeix un entorn de treball pel desenvolupament àgil del software, i se centra en els projectes de sistemes d'informació de pressupostos ajustats. D'acord amb el DSDM el prototip pot ser un diagrama, un procés de negoci o fins i tot un sistema col·locat en la producció. Els DSDM prototips són iteratius i que evolucionen des de formes simples fins a unes de més complexes. Per això han de ser sensibles als canvis. Aquests canvis són reversibles. Involucrar el client és la clau per obtenir un projecte eficient i efectiu. Els DSDM prototips poden ser o throwaway o evolutionary:

Les quatre categories de prototips recomendats pel DSDM són:

  • Prototips comercials – utilitzats per demostrar que els processos de negoci estiguin automatitzats.
  • Prototips d'usabilitat – utilitzats per definir, refinar i demostrar la usabilitat del disseny de la interfície d'usuari.
  • Prototips de rendiment i de capacitat – utilitzats per definir, demostrar i preveu-re com actuarà el sistema sota grans pics de demanda i per avaluar aspectes no funcionals del sistema (temps de resposta, volum d'emmagatzematge de les dades, ràtios de transacció).
  • Prototips de capacitat i tècnica - utilitzats per desenvolupar, demostrar i avaluar un concepte de disseny.

Mètode de prototips operacional[modifica]

El mètode de prototips operacional va ser proposat per l'Alan Davis com una manera d'integrar els prototips throwaway i evolutionary. La seva idea consisteix en una metodologia de propotip evolutiva. Combina els advantatges tant del throwaway com del evolutionary. Amb aquest mètode obtenim resultats ràpids sense perdre la qualitat. La seva metodologia segueix els següents passos:[18]

  • Un evolucionari prototip es construeix utilitzant les estratègies de desenvolupament convencionals, especificant i implementant els requeriments.
  • Còpies d'aquesta estructura són enviats a diversos clients.
  • Quan l'usuari troba un problema o vol afegir un nou requeriment, el protopitat ho registra.
  • Quan la sessió del sistema ha finalitzat, el protopitat construeix un throwaway prototip a dalt del sistema.
  • L'usuari ara utilitza el nou sistema i l'avalua. Si els canvis no són efectius, el protopitat els elimina.
  • Si a l'usuari li agraden els canvis, el protopitat escriu les peticions de millora i les envia a l'equip de desenvolupament.
  • L'equip de desenvolupament, amb els canvis demanats per l'usuari produeix un nou prototip evolucionari utilitzant mètodes convencionals.

Desenvolupament de sistemes evolutius[modifica]

El desenvolupmanet de sistemes evolutius és una sèrie de metodologies que pretén implementar el prototip evolucionari. Un particular tipus, anomenat Systemcraft és descrit per en John Crinnion en el seu llibre anomenat Evolutionary Systems Development. El Systemcraft va ser dissenyat com una metodologia prototip que hauria de ser modificada i adaptada per encaixar en l'entorn en el qual s'ha desenvolupat. El Systemcraft no va ser dissenyat com un enfocament rígid sinó com una metodologia prou flexible per ajustar-se a qualsevol entorn i situació.[3] Les bases del Systemcraft és crear un sistema que funcioni a partir dels requeriments inicials i anar-lo construint a mesura que fem les revisions. El Systemcraft posa l'èmfasi en anàlisis tradicionals que són utilitzats en el desenvolupament del sistema.

Desenvolupament ràpid i evolucionari[modifica]

El desenvolupament ràpid i evolucionari (ERD) va ser desenvolupat pel Software Productivity Consortium, un departament de tecnologia i d'integració de l'oficina de tecnologia i informació de l'Agència de Projectes d'Investigació Avançats. (DARPA)

ERD es basa en el concepte de crear sistemes de software patrons de disseny basats en la reutilització de components i l'ús de patrons de disseny. La continua evolució del sistema de capabilities en resposta a les canviants necessitats dels usuaris i de la tecnologia es destaca en l'arquitectura.

El sistema està organitzat per permetre l'evolució d'un conjunt de capabilities que inclouen consideracions pel rendiment, capacitat i funcionalitat. L'arquitectura es defineix en interfícies abstractes que encapsulen la seva implementació.

L'arquitectura serveix com a plantilla per ser utilitzada per guiar el desenvolupament de més d'una instància del sistema. Permet que múltiples components de l'aplicació ho implementin.

El ERD procés està estructurat per utilitzar la funcionalitat. Per fer-ho s'utilitza el mètode “timebox”. Aquest mètode consta de períodes fixes de temps on determinades tasques s'han d'executar. El temps és fix i els objectius es poden aconseguir dins d'aquestes limitacions.

Un cop l'arquitectura és establerta el software s'integra i es testeja. Això permet identificar els problemes ràpidament i avaluar el procés de manera objectiva. Com que les petites quantitats del sistema estan integrades, eliminar els defectes és un procés poc laboriós.

Eines[modifica]

Per tal de construir de manera eficient els prototips, es requereixen una seria d'eines adequades i un personal capaç d'utilitzar-les. Aquestes poden variar des d'eines individuals, com la 4r Generacio de Llenguatges de programació visual utilitzats per la creació ràpida d'eines CASE que donen suport a l'anàlisi dels requisits. D'aquestes, els més utilitzats són el Visual Basic i el ColdFusion, ja que són barats i relativament fàcils i ràpids de fer servir. Altres poden ser les Requierements Engineering Environment que solen ser desenvolupats per l'exercit o grans organitzacions. També altres eines orientades a objectes estan desenvolupades per la LYMB del Centre de Recerca i Desenvolupament de la GE. Els usuaris, siguin del tipus que siguin, poden crear prototips d'elements d'una aplicació per ells mateixos en un full de càlcul.

Com que les aplicacions web creixen en popularitat, també s'han de tenir eines per la creació de prototips d'aquest tipus. Marcs de treball com Bootstrap, Foundation i AngularJS proporcionen les eines necessàries per crear prototips d'aplicacions web de manera ràpida.

Generadors de pantalla, eines de disseny i fàbriques de programari[modifica]

Se solen utilitzar els generadors de pantalla encara que no mostrin la funció real, ja que en mostren una que s'hi assembla.[19] El desenvolupament de la Interacció persona-ordinador a vegades pot resultar la part més critica de l'esforç de desenvolupament, ja que per als usuaris la interfície és essencial en el sistema.

Les Fabriques de programari poden generar codi per mitjà de components modulars preparats pel seu ús. Gràcies a això, són ideals per utilitzar-les en la creació de prototips, ja que amb aquest enfocament es poden crear ràpidament programes amb el comportament desitjat i amb la menor quantitat de codificació manual.

Definició d'aplicacions o programari de simulació[modifica]

Aquest nou tipus de programari, permet crear ràpidament lleugeres simulacions animades d'un altre programa d'ordinador i sense necessitat d'escriure codi. El programari de simulació permet tant els usuaris tècnics com els no tècnics, experimentar, provar, col·laborar i validar el programa simulat, i obtenir informes i/o anotacions en captures de pantalla i esquemes. Com a solució per l'especificació, el programari de simulació es troba en els de baix risc, ja que els textos, maquetes, documents basats en prototips i els prototips basats en codis, proporcionen al desenvolupador la possibilitat de validar els requisits del prototip des del començament. Gràcies a això, els riscos i els costos associats en les implementacions de programari es poden reduir dràsticament.

Per simular les aplicacions, també es pot utilitzar programari simulador del món real per la tecnologia educativa, la demostració i l'atenció al client, com ara els Programes de screencasting estan estretament relacionades. També hi ha eines més especialitzades.[20]

REE[modifica]

El REE (Requirements Engineering Environment) proporciona un conjunt d'eines per representar, construir i executar models dels aspectes crítics dels sistemes més complexos.

El REE està format per 3 parts:

  • Eines CASE dissenyada per augmentar la productivitat reduint el cost i el temps de producció.
  • RIP(Rapid Interface Prototyping System) consisteix en una sèrie d'eines que faciliten la construcció d'interfícies d'usuari.
  • La tercera part és una interfície d'usuari a RIP.

El Rome Laboratory és el creador del REE, el seu mètode consta de 3 parts.

  • Analitzar que les necessitats de diversos usuaris no siguin problemàtiques entre elles i són viables econòmicament.
  • La validació dels requeriments han de ser un reflex de les necessitats de l'usuari.
  • Investigar sobre diverses fonts l'especificació i la comprovació de coherència.

El 1996 el Rome Laboratory va contractar Software Productivity Solutions (SPS) per millorar el REE i crear un REE comercial i de qualitat que suporti els requeriments d'especificació, simulació, la representació sobre els requisits arquitectònics, la interfície d'usuaris i la generació de codi.[21]

Ara aquest sistema s'anomena AREW (Advanced Requirements Engineering Workstation).

LYMB[modifica]

El LYMB és un entorn de desenvolupament orientat a objectes que permet als usuaris crear aplicacions orientades a objectes i proporciona una interactiva intefície a aquestes aplicacions.

PSDL[modifica]

El PSDL és un llenguatge de descripció per descriure programari en temps real fet que provoca que hi hagi dependències d'implementació i de hardware. Per solucionar aquestes dependències el PSDL introdueix abstraccions de control que inclouen restriccions temporals.[22] L'eina associada és el CAPS (Computer Aided Prototyping System).[23] El CAPS utilitza tota aquesta informació anterior per generar codi automàticament i monotiritzar les limitacions de temps durant l'execució del prototip i simular l'execució proporcional en temps real realitiu a una sèrie de models de maquinari parametritzats.

Referències[modifica]

  1. Grimm, Todd. The Human Condition: A Justification for Rapid Prototyping. Time Compression Technologies Vol. 3 No.3 (en anglès). Accelerated Technologies, Inc., Maig 1991, p. 1. 
  2. Smith, Michael F. Software Prototyping: Adoption, Practice and Management (en anglès). Londres: McGraw-Hill, 1991. 
  3. 3,0 3,1 3,2 3,3 3,4 3,5 John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping :within a structured systems methodology. Plenum Press, New York, 1991. Page 18.
  4. Dewar, Robert B. K.; Fisher Jr., Gerald A.; Schonberg, Edmond; Froelich, Robert; Bryant, Stephen; Goss, Clinton F.; Burke, Michael «The NYU Ada Translator and Interpreter». ACM SIGPLAN Notices - Proceedings of the ACM-SIGPLAN Symposium on the Ada Programming Language, 15, 11, novembre 1980, pàg. 194–201. DOI: 10.1145/948632.948659.
  5. SofTech Inc., Waltham, MA. «Ada Compiler Validation Summary Report: NYU Ada/ED, Version 19.7 V-001», 11-04-1983. Arxivat de l'original el 2012-03-12. [Consulta: 16 desembre 2010].
  6. Nielsen, Jakob. Usability Engineering (en anglès). Morgan Kaufmann, 23 de setembre de 1993, p. 362. ISBN 0125184069. 
  7. 7,0 7,1 7,2 S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design :Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, :Virginia.
  8. Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
  9. Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.
  10. Davis. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM, Aug. 1991, pp. 104–118
  11. www.softdevteam.com/ Incremental- lifecycle.asp
  12. Què és el mètode incremental? – avantatges, inconvenients i quan s'ha de fer servir
  13. «Metodologia:: Desenvolupament de mètodes». Arxivat de l'original el 2016-03-03. [Consulta: 24 octubre 2015].
  14. Software Evolution through Rapid Prototyping (en anglès). IEEE Computer, Maig 1989. 
  15. Adapted from C. Melissa Mcclendon, Larry Regot, Gerri Akers.
  16. Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY.
  17. Dynamic Systems Development Method Consortium. http://na.dsdm.org Arxivat 2006-02-09 a Wayback Machine.
  18. Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
  19. [1] List of common UI prototyping tools
  20. Top 10 Simulation Tools for UI Designers, Information Architects and Usability Specialists
  21. Software Productivity Solutions, Incorporated. Advanced Requirements Engineering Workstation (AREW). 1996. [2] Arxivat 2007-09-27 a Wayback Machine.
  22. Luqi; Berzins, Yeh «A Prototyping Language for Real-Time Software». IEEE Transactions on Software Engineering, 14, 10, octubre 1988, pàg. 1409–1423. DOI: 10.1109/32.6186.
  23. Luqi; Ketabchi «A Computer-Aided Prototyping System». IEEE Software, 5, 2, març 1988, pàg. 66–72. DOI: 10.1109/52.2013.