12/11/2008

1

Los diez mandamientos Los diez mandamientos de los Mtodos Formalesde los Mtodos Formales

Autoras de GRUPO1: Autoras de GRUPO1:

Luca Nez Anta DNI: 44445050Luca Nez Anta DNI: 44445050--BBMara Gmez Rodrguez DNI: 44471229Mara Gmez Rodrguez DNI: 44471229--QQRomina Carrera Arjolekas DNI: 36165745Romina Carrera Arjolekas DNI: 36165745--QQ

IntroduccinIntroducciny Los Mtodos Formales tcnica para conseguir

sistemas de alta integridadsistemas de alta integridad.y Aunque su uso sigue siendo an la excepcin, su

uso para problemas de la vida real, consigue destacar que los MF cumplen los requisitos establecidos.

y Factores que tendrn gran influencia para saber si un MF tendr o no xito: Diez mandamientossi un MF tendr o no xito: Diez mandamientos.

12/11/2008

2

1. Elegir la notacin apropiada1. Elegir la notacin apropiaday Principal herramienta: lenguaje de especificacin.

Interrelacin entre expresividad del lenguaje y y Interrelacin entre expresividad del lenguaje y niveles de abstraccin.

y El vocabulario no es la nica tarea a considerar.y Es ms apropiado un proceso algebraico

atendiendo a los aspectos basados en estados del sistema (CSP, CCS).N t i bi t bl id it dy Notacin bien establecida, xito asegurado.

2. Formalizar, pero no en exceso2. Formalizar, pero no en excesoy Realmente necesitamos Mtodos Formales?y En algunas reas son mejores los mtodos convencionales (ejm.: g j ( j

IU).y Aplicar Mtodos Formales a todos los aspectos del sistema,

innecesario y costoso.y Si se necesitan mtodos formales y una vez elegida la notacin

apropiada e identificando esos componentes del sistema, en qu nivel se van a emplear los mtodos formales?

y Nivel 1: Especificacin Formal.y Nivel 2: Desarrollo/verificacin formaly Nivel 2: Desarrollo/verificacin formal.y Nivel 3: Comprobacin mecnica de pruebas.y Peroel coste est justificado? (sistemas de alta integridad,

prdida de vida humana, gran prdida financiera)

12/11/2008

3

3. Estimacin de los costes3. Estimacin de los costesy La introduccin inicial de MF puede requerir una

gran inversin Sin embargo podrn funcionar a gran inversin. Sin embargo, podrn funcionar a tan bajo costo (o incluso menor) que los convencionales.

y Todava no existen mtricas de especificaciones formales para estimarlos.

y Muchos proyectos de MF en dominios especializados Poco representativosespecializados. Poco representativos.

y En sistemas de alta integridad, se garantiza la inversin.

4. Disponer de un experto en MF4. Disponer de un experto en MF

y Es muy difcil aprender a usar MF sin ayuda de un expertoun experto.

y IBM: realizacin de cursos de capacitacin. Se convierte en auto-suficiente (no necesita la ayuda de expertos).

y IMNOS: los consultores matemticos y los ingenieros son separados como fuente de conocimientos La comunicacin entre los dos conocimientos. La comunicacin entre los dos grupos da el xito asegurado.

y Si es necesario se solicita ayuda a una consultora externa.

12/11/2008

4

5. No abandonar los mtodos 5. No abandonar los mtodos tradicionales de desarrollotradicionales de desarrollo

y Arriesgado sustituir las tcnicas de desarrollo de software por MF software por MF.

y Solucin: integrar los MF en el proceso de diseo en funcin de los costos efectivos.a. Combinar un MF con un mtodo estructurado ya

existente en la industria.b. Integrar ambas tcnicas para revisar un proceso ya

existente.

y Ventaja: se pueden capturar muchos errores antes de que sea demasiado tarde y caro de corregir.

6. Documentar suficientemente6. Documentar suficientemente

y Muy importante en el diseo del sistema:Menor ambigedadMenor ambigedadMenor probabilidad de errores

y Contenido ideal:Requisitos del sistemaEspecificacin formalDescripcin del lenguaje natural (si procede)

y Se recomienda: producir una especificacin p pinformal y explicar la descripcin formal. En caso de duda se tomar como elemento final la descripcin formal (menos ambigua).

12/11/2008

5

7. No comprometer los estndares 7. No comprometer los estndares de calidadde calidad

y Los MF son un medio de lograr la mayor integridad de los sistemas cuando se aplican integridad de los sistemas cuando se aplican adecuadamente.

y La organizacin debe asegurarse de que sigue cumpliendo con sus normas de calidad:garantizar la adecuada retroalimentacin entre los equipos de

desarrollo y gestingarantizar la continuidad de la inspeccin de los programas y el

mantenimiento de polticas de pruebasmantenimiento de polticas de pruebasasegurar que la documentacin del sistema cumple con los estndares

de calidad que se establecieron para los mtodos convencionales de desarrollo.

y Norma de calidad del Software ISO9000.

8. No ser dogmtico8. No ser dogmticoy Los mtodos formales no son una solucin

universal para cualquier desarrollo informticouniversal para cualquier desarrollo informtico.y Un desarrollo formal no siempre estar libre de

errores (se reducen y son fcilmente localizables).

y No ser suficiente para la implementacin un desarrollo simple y lineal.Admitir errores y no tomar pruebas como y Admitir errores y no tomar pruebas como definitivas.

12/11/2008

6

9. Probar, probar y probar otra vez9. Probar, probar y probar otra vez

y Dijkstra: Las pruebas de los programas pueden usarse para demostrar la presencia de errores usarse para demostrar la presencia de errores pero nunca para demostrar su ausencia.

y Las pruebas siempre sern un til comprobante de que un sistema producido formalmente funciona en el mundo real.

y La especificacin inicial ser utilizada para ayudar a realizar pruebas unitarias en una fase ayudar a realizar pruebas unitarias en una fase ms temprana del desarrollo de SW Reduccin de costes de mantenimiento del sistema.

10. Reutilizar10. Reutilizary Reutilizar SW reduce costes.

La reutilizacin depender del tipo de sistema y La reutilizacin depender del tipo de sistema que se est a desarrollar afectando diversos factores ( tamao de aplicacin, eleccin de componentes a reutilizar ).

y Lenguajes de especificacin formal proporcionan requisitos del sistema o de componentes de un sistema no ambiguos bien documentados y sistema no ambiguos, bien documentados y especificados ideales para ser combinados si fuera necesario para formar un nuevo sistema.

12/11/2008

7

CONCLUSIONESCONCLUSIONESy Decidir que mtodo formal ser ms adecuado a

cada casocada caso.y Escoger notacin apropiada que mejor se ajuste

a los procesos de desarrollo, intentando seguir las pautas y procedimientos explicados para obtener el xito de MFS.

y Reconocer errores y mantener una fase de pruebas iterativa con la ayuda de herramientas pruebas iterativa con la ayuda de herramientas automatizadas para as obtener el xito de sistemas de alta integridad usando mtodos formales.

LOS DIEZ MANDAMIENTOS DE LOSMTODOSFORMALES

AutorasGRUPO1:

LucaNezAnta.DNI:44445050B

MaraGmezRodrguez.DNI:44471229Q

RominaCarreraArjolekas.DNI:36165745Q

2

NDICE

Introduccin..............................................................................................................................3

1. ............................................................................3Sedeberelegirlanotacinapropiada

2. .............................................................................4Sedebeformalizar,peronoenexceso

3. ..............................................................................................5Sedebenestimarloscostes

4. ..............................................................5Sedebetenerunexpertoenmtodosformales

5. ...................................6Nosedebenabandonarlosmtodosdedesarrollotradicionales

6. ......................................................................6Sedeberealizarsuficientedocumentacin

7. .................................................7Nosedebenponerenpeligrolosestndaresdecalidad

8. ..............................................................................................................7Noserdogmtico

9. ...........................................................8Sedebeestarenuncontinuoprocesodeprueba.

10. ...........................................................................................................9Sedebereutilizar

Conclusiones...........................................................................................................................10

PREGUNTAS.............................................................................................................................11

3

Introduccin

Los mtodos formales son definidos como una tcnica con la que se consigue, msprobablemente,sistemasdeunaaltaintegridad.

Desafortunadamente,suusotodavasiguesiendo,ms laexcepcinque laregla;debido,enbuenaparte,alosgastos,dificultades,etc.

Sinembargo,suusoparaproblemasdelavidareal,estayudandoadestacarelhecho,dequelosproyectosqueempleanmtodosformales,cumplen losrequisitosestablecidos:entregaatiempo, dentro del presupuesto y produciendo un software (y hardware) correcto, bienestructuradoymantenido.

Hay una serie de factores que pueden tener una gran influencia a la hora de saber si unproyectodemtodosformalestieneonoxito.

Los mandamientos expuestos a continuacin, se basan en un nmero de proyectosrecientementecompletadosexitosamente.

1. Sedeberelegirlanotacinapropiada

El lenguajedeespecificacines laprincipalherramientaen lasetapas inicialesdeldesarrollodelsistema.Debertenerunassemnticasformalesbiendefinidas.

Paraelegir lanotacin,esnecesariounciertogradode interrelacinentre laexpresividaddeunlenguajedeespecificacinylosnivelesdeabstraccinquesoporta.

Algunos lenguajes pueden tener un vocabulario y construccin extensos para soportarsituacionesparticulares;peronos forzarnaunas implementacionesparticularesymientrasempequeecelasespecificaciones,generalmente,lashacemenosabstractas.

Por otro lado, los lenguajes con vocabularios menos extensos, obtienen grandesespecificaciones,ofreciendoaltosnivelesdeabstraccinyunaimplementacinmspequea.

Elvocabularionoeslanicatareaaconsiderar;porejemplo,intentarespecificarunsistemaconcurrente en un lenguaje de especificacin basado en modelos, como Z o VDM, podrhacerse,peronoeslamejormanera.

EsmsapropiadounprocesoalgebraicocomoCSPoCCS,atendiendoa losaspectosbasadosenestadosdelsistema.

Una notacin bien establecida, con una buena base de usuario, asegurar el xito de laaplicacinenlasmodificacionesindustriales.

4

Una parte importante de la aceptacin general de una notacin, es la produccin de unestndar internacional.Resulta esencial tenerun surtidode estndarespara garantizarunauniformidadrazonableyunconjuntodeherramientascompatiblesparasoportarlanotacin.

Nodebemos conformarnos conunanotacinde especificacin estndar, yaquepuede sermsproblemticocomparadoconunlenguajedeprogramacin.

2. Sedebeformalizar,peronoenexceso

Muchas empresas adoptan innecesariamentemtodos formales. Siendo realista, loprimeroquedebedeterminarsees si realmente senecesitanusarmtodos formales;esdecir, si sedesea un incremento de confianza en el sistema, para satisfacer el estndar particularrequerido,paraganarcomplejidad,etc.

Hayreasdondelosmtodosformalesnosontanbuenoscomolosmtodosconvencionales.En eldiseode la interfazdeusuario,por ejemplo, aunquehubo algunas aplicacionesqueutilizaron tcnicas de especificacin formal con xito, est aceptado que su diseo caigadentrodeldominiodelrazonamientoinformal.

Aplicarmtodosformalesatodoslosaspectosdelsistema,podrasertantoinnecesariocomocostoso.Slounodecadadiezsistemassonobjetodeundesarrolloformal.

Habiendodeterminadoqueunorealmentenecesitalosmtodosformalesyunavezelegidalanotacin apropiada e identificando esos componentes del sistema, uno debe considerar elnivelenelculvaaemplearlosmtodosformales.

Seidentificantresniveles:

1.Especificacinformal

2.Desarrollo/verificacinformal3.Pruebasmecnicasdecomprobacin

Cadaunodeestostresnivelesestilensmismo.Sinembargo,hayquedeterminarsielcosteadicional est justificado. Para sistemas donde se requiere lams alta integridad, es decir,donde la prdida de vida humana, una gran prdida financiera o la destruccinmasiva depropiedades,podra serel resultadodel fracasodel sistema; tal inversinpodraestarmuybienjustificadayrequerida!

5

3. Sedebenestimarloscostes

Laintroduccininicialdelosmtodosformalesenunambientededesarrollo,probablementerequierecantidadessignificativasdeentrenamiento,laconsultadelcontratoylainversinenherramientasdeapoyo.

Losmtodosformalespuedenfuncionartanabajocoste(yposiblementeamenorcoste)queproyectosdesarrolladosusandomtodosconvencionales.

Que los mtodos formales sean ms caros por ellos mismos, es ms bien sintomtico delhechoquesonusadosensistemascaros,sobretodosirequerimosaltosnivelesdeconfianzaensucorrectaoperacin.

Sehanaplicadoanmtodosformalesaunnmerosuficientedeproyectosparadeterminarlas tendencias y muchos proyectos con mtodos formales estn en dominios muyespecializados, poco probables de ser tratados muy regularmente, por tanto son pocorepresentativos.

Aunquenoseafirmeque losmtodosformalessonbaratos;slosernparasistemasdealtaintegridaddondesegaranticelainversin.

Eltiempoesunpuntodecomienzotilparaextenderlosmodelosexistentes,contalquenospermitasuficientesmrgenesdeerror.

4. Sedebetenerunexpertoenmtodosformales

La mayora de proyectos exitosos realizados utilizando mtodos formales han accedido almenosaunconsultorexpertoenelusode tcnicas formales.Esmuydifcilaprenderausarmtodosformalessinayudadeunexperto.

En el caso de IBM se han realizado cursos de capacitacin y poco a poco un significantenmerodepersonasadquirieronfluidezenlaaplicacindetcnicasformales.As,finalmenteIBMseconvirtienautosuficienterespectoalusodemtodosformales,yaquenonecesitaayudacontinuadeexpertosexternos.

EnINMOSfueadoptadounenfoquediferente.Enestecaso,losconsultoresmatemticosylosingenierossonseparadoscomofuentedeconocimientos.Sinembargo,lacomunicacinentrelosdosgruposdaelxitoasegurado,amenosquelosmatemticosylosingenierosnopuedanapreciar la funcin y problemas de los dems, ya que en este caso el xito ser difcil dealcanzar. Cuando se considera necesario, se solicita ayuda a una consultora externa parasolucionarproblemasespecficos.

6

5. Nosedebenabandonarlosmtodosdedesarrollotradicionales

Existeunaconsiderable inversinen lastcnicasdedesarrollodesoftwareyseraarriesgadosustituir estos por mtodos formales. En su lugar, es conveniente integrar los mtodosformalesenelprocesodediseoenfuncindeloscostosefectivos.Unamaneradehacerloesinvestigarcmounmtodoformalyaexistentesepuedecombinardemaneraefectivaconunmtodoestructuradoexistenteyyaenusoenlaindustria(porejemploelmtodoSAZ,queesunacombinacindeSSADMyZ).

Lo ideal sera la combinacin de los dos mtodos, obtenindose as la mayora de losbeneficiosoventajasdeambos,comoporejemplolamayorprecisinenlaespecificacinqueofrecenlosmtodosformalesymejorpresentacinparaunapersonanoexpertaqueofrecenlosmtodosestructurados.

Otraalternativaalaintegracindeambastcnicaseselusodemtodosformalespararevisarunprocesoyaexistente.Paraproporcionarinformacinaunequipodediseopuedenusarselos mtodos tradicionales de desarrollo teniendo un equipo de anlisis separado de losprincipiosdeespecificacinformalenelprocesodediseo,por lotanto,sepuedencapturarmuchoserroresantesdequeseademasiadotardeycarodecorregir.EstosehaaplicadoenZconmuchoxitoenfuncindeloscostosefectivos.

Otro ejemplo es Cleanroom, una tcnica que podra incorporar el uso de las notacionesformales. Esta tcnica se ha aplicado conmucho xito utilizando tcnicas de desarrollo desoftware con un historial demostrado de reducir errores, para el resultado de aplicacionessegurasynocrticas.Siseencuentrandemasiadoserrores,debersermodificadoelprocesoantesqueelprograma.

Desdeelpuntodevistadel lenguaje, losprogramas reales sondemasiadograndespara serprobadosdemaneracorrecta,porloquedebenserescritoscorrectamenteenprimerlugar.Avecesesposiblecombinardiferentesmtodosformalestilesyefectivos,comoporejemploHOL,quehasidoutilizadoparaproporcionarherramientadeapoyoaZ, locualpermitequesea ms legible y aumenta la confianza en el desarrollo debido a las pruebas mecnicaschequeadasporHOL.

6. Sedeberealizarsuficientedocumentacin

Ladocumentacinesunapartemuy importanteeneldiseodelsistema,yaqueconduceauna menor ambigedad y por lo tanto menos probabilidad de errores. En el caso de laseguridaddelossistemascrticos,losproblemasdetiemposeconviertenensignificativosylosmtodosparadocumentarlossonespecialmenteimportantes.

7

Lo idealseraque ladocumentacindelsistemacontuviese los requisitosy laespecificacindel sistema en una notacin formal adecuada y acompaada, cuando proceda, de ladescripcindellenguajenatural.

En general, esmuy recomendable producir una especificacin informal y almismo tiempoexplicarladescripcinformal.Sihayalgunadiscrepanciaentrelosdos,laespecificacinformaldebe ser tomada como el elemento final de la documentacin ya que este es el menosambiguodelasdosdescripciones.

7. Nosedebenponerenpeligrolosestndaresdecalidad

Hasta hace poco tiempo, apenas han existido estndares que estuvieran pensadosespecficamenteenelsoftwaredondesepuedenaplicarmtodosformales,comoporejemplolaseguridadenlossistemascrticos.

Unade lasnormasdecalidaddesoftwarees la ISO9000,quesepuedenaplicarencualquiertipodeorganizacinqueestorientadaalaproduccindebienesoservicios.Secomponendeestndaresyherramientasespecficascomo losmtodosdeauditoria paraverificarque lossistemasdegestincumplenconelestndar.Su implantacinunagrancantidaddeventajasparalasempresascomomejorarlasatisfaccindelcliente,mejorarlosprocesosrelacionadosconlacalidad,reduccindeincidenciasenlaproduccinoaumentodelaproductividad.

Errneamentelosdesarrolladorespuedenverenlaaplicacindemtodosformalesunmedioparaelcorrectodesarrollodesoftware,siendostos,porelcontrario,unmediode lograr lamayor integridad de los sistemas cuando se aplican adecuadamente. A pesar de todo, laorganizacin debe asegurarse de que sigue cumpliendo con sus normas de calidad. Estoincluye garantizar la adecuada retroalimentacin entre los equipos de desarrollo y gestin,garantizarlacontinuidaddelainspeccindelosprogramasyelmantenimientodepolticasdepruebas,ascomoasegurarque ladocumentacindelsistemacumplecon losestndaresdecalidadqueseestablecieronparalosmtodosconvencionalesdedesarrollo.

8. Noserdogmtico

Con estemandamiento se quiere expresar que losmtodos formales no son una solucinuniversal a cualquier desarrollo informtico. El usarlos o no, y saber cul es la notacincorrecta paraun desarrollodepende de las caractersticasdel sistema a implementar. Porejemplo,sehademostradoqueestaseriedetcnicassonespecialmentetilesensistemasdeinformacincrtica,esdecirendesarrollosdondelaintegridadesvital.

Pero,estonoquieredecirque,haciendousodeestastcnicasunaaplicacinsoftware:

8

Estar completamente libre de errores; se asegura que usandomtodosformales,loserroressereducenconsiderablementeysonmasfcilmentelocalizablesduranteeldesarrollodeunaaplicacin,peronogarantizansuausencia.

Acausadelprimermotivonosersuficienteundesarrollosimple, lineal;con mtodos formales al igual que con mtodos convencionales sernecesarialapresenciadeunacontinuafaseiterativaduranteeldesarrollodelsoftware.

Portanto,enestemandamientosetratadeconcienciaraldesarrolladordelaimportanciadeadmitir los errores que pueden surgir usando mtodos formales, como por ejemplo, noescogerunnivelde abstraccin adecuadoparaunaespecificacin yde concienciarlodenotomarpruebascomodefinitivasporelsimplehechodeacabarunafasedeldesarrollo.

9. Sedebeestarenuncontinuoprocesodeprueba.

AqutenemosunacitadelDijkstraquedice:Laspruebasdeprogramaspuedenusarseparademostrarlapresenciadeunerrorperonuncaparademostrarsuausencia

Conestoloquequieredeciresquemientrashayapresenciadeerrores,laspruebasnuncahandedesaparecer.

Laingenieradelsoftwareesuntrabajorealizadoporpersonas,locualvaaimplicarqueeneldesarrollodeunaaplicacinhayapresenciadeerroresdebidoanuestrahabilidadinnataparaprovocarlos. Por lo tanto, no debemos subestimar la fiabilidad humana, y las pruebas quevayamos haciendo siempre sern un til comprobante de que un sistema producidoformalmentefuncionaenelmundoreal.

Eneste temaesdnde losmtodos formalesadquierenmayor importancia yaqueofrecenventajas considerables, como es que nos permiten verificar que la implementacin secorrespondeconlaespecificacininicial.

Portanto,laespecificacininicialserutilizadaparaayudararealizarlaspruebasunitariasenuna fase ms temprana del desarrollo del software, para as poder reducir los costes demantenimientodelsistema.

Perohayque tenerencuentaque, apesardequenosaportenunamayorconfianzaen laintegridaddelsistemayunamayorconfianzaenqueelsistemafuncionacomoenunprincipioseesperaba,stosnogarantizanenunaimplementacinunaabsolutacorreccin.

9

10. Sedebereutilizar

Todos sabemosqueen los sistemas llevadosacabomediantemtodosconvencionalesestmsque comprobado que la reutilizacinde software, incluyendo cdigo,especificaciones,diseo y documentacin ayuda a disminuir considerablemente el conjunto de costes deldesarrollo.Puesbien,enundesarrolloformalocurreexactamentelomismopudiendoreducircostestantoenherramientascomoenformacin.

Esta reutilizacin depender del tipo de sistema que se est a desarrollar afectando entreotrosmotivoslossiguientes:

Eltamaodeaplicacin;cuantomsgrandesealaaplicacinmsespecializadaseryporlotantomasdifcilsersureutilizacin.

Laeleccindequcomponentessonmsadecuadosparaincluirenlalibreraparasuposteriorreutilizacinolaconfianzaquetenemosonodeesoscomponentes.

Elusodelosmtodosformaleseneldesarrollodelsistemacontribuyealaventajadereutilizarelsoftware,yaque los lenguajesdeespecificacin formalproporcionarunmediodeestadonoambiguodelosrequisitosdeunsistema,odelcomponentedeunsistema.

Aspues, se podrn identificar los componentesquehan sido formalmente especificados ysuficientementebiendocumentados,reutilizadosycombinadosparaformarloscomponentesdelnuevosistema.

Por tanto, los problemas con los diversos componentes que forman parte de una libreradisminuyen, aumentando la confianza en la integridad de los componentes, ya que cadacomponenteesclaramenteespecificado,ypuedetenerdiferentespropiedadespropuestasydemostradas.

10

Conclusiones

Paragarantizarelxitode laaplicacindemtodosformalesenuncontexto industrialhabrquedecidirantesdenadaquemtodoformalsermsadecuadoacadacaso.

Por tanto se ha de escoger la notacin apropiada que mejor se ajuste a los procesos dedesarrollo de la aplicacin determinada, intentado siempre garantizar que estas pautas yprocedimientos se mantengan en la medida de lo posible para obtener el xito de laindustrializacindelosMFS.

Hayque tenerencuentaque la IngenieradelSoftwareesunaactividadhumanaquenuncaestar libre de errores ya sea desarrollada por medio de un mtodo formal comoconvencional,porloquesiempretendrqueexistirunafasedepruebasiterativacomoelusoadecuadodeherramientasautomatizadas,paraobtenerelxitodesistemasdealtaintegridadusandomtodosformales.

11

PREGUNTAS

Qupodemoslograrutilizandomtodosformales?

Un correcto desarrollo de software. (Falso, no se tiene porque conseguirobligatoriamenteporusarmtodosformales).

Unamayorintegridaddelossistemascuandoseaplicanadecuadamente.

Disminuir el coste del proyecto. (Falso, algunas veces el coste esmenor que en undesarrolloutilizandomtodosconvencionales,yotrasvecesestecosteessuperior).

Mejor presentacin para una persona no experta. (Falso, esto es un beneficio queofrecenlosmtodosestructurados,nolosmtodosformales).

Qupuntosfundamentalesdebetenerunabuenadocumentacin?

- Ladescripcindellenguajenatural.(Falso,noesunarespuestacompleta,yademsnosiempreesimportanteincluirladescripcindellenguajenaturalenladocumentacin).

- Ladescripcindelestndardecalidadusado.(Falso,dependedeltipodeproyectoynoesunfactorimportanteparaunabuenadocumentacin).

- Los requisitos, la especificacin del sistema y la descripcin del lenguaje natural, siprocede.

- El nivel en el cul se han empleado los mtodos formales. (Falso, ya que estainformacinesnecesariaparapoderemplearmtodosformalesperonopararealizarunabuenadocumentacin).

Cundosedeberanutilizarlosmtodosformales?

- Siempre, porque aunque los costes sean altos, los mtodos formales harn quenuestro proyecto sea ms fiable y comprensible. (Falso, ya que en el diseo de lainterfaz de usuario, por ejemplo, es mejor el uso de especificaciones informales.Ademsaplicarlosmtodosformalesatodoslosaspectosdelsistema,puedesertantoinnecesario como costoso. Por otro lado, dependiendo del tipo de proyecto adesarrollar,loscostespuedenserigualesomenoresqueconmtodosconvencionales).

- Slocuandoserequiera lamsalta integridad,yaque losmtodosformalessonunatcnicaparaconseguirlo.

12

- Debenutilizarseenproyectosdonde laprdidadevidahumana,prdidafinancieraoladestruccinmasivadepropiedades,provoqueun fracasodel sistema;peronuncapara incrementar la confianza en el sistema, ganar complejidad o satisfacer unestndar,yaqueesungastoinnecesario.(Falso,porquetodaslasopcionessonbuenasrazonesparautilizarlosyjustificansugasto).

- No sedebenutilizarnunca. (Falso, ya sehandado razonesmsque suficientesquejustificansuusoyportantoestarespuestacarecedesentido).

Quhacequeunproyectodemtodosformalestengaxito?

- Escogerelmtodoformalmsadecuadoyseguirunaseriedefactores(comoelegirlanotacinadecuada,estimarcostes,etc.).

- Seguir losmandamientos al pie de la letra. (Falso, ya que en algunos casos puederesultartantoinnecesariocomocostoso).

- Esunapreguntamuysubjetivaquenosepuederesponder.(Falso,yaqueapesardeserunapreguntasubjetiva,sepuederesponder).

- Tenerunexpertoenmtodosformaleses loniconecesarioparatenerunproyectoexitoso.(Falso,yaqueesunadelascosasnecesarias,peronolanica).

Quimplicanlosmtodosformales?

- Larenunciaalusodelosmtodostradicionalesdediseo.(Falso,yaqueelusodelosmtodosformalesdependerdeltipodeaplicacinaimplementar).

- La perfeccin del software haciendo innecesaria su verificacin. (Falso, el uso demtodos formales reduce considerablemente la presencia de errores y ayuda aencontrarlosmsfcilmente,peronogarantizasuausencia).

- Unaumentoen loscostesdedesarrollo. (Falso,elcostededesarrollopuede llegarasermsreducidoqueusandomtodosconvencionales).

- Altaintegridadenaplicacionesquelorequieren.

Los diez mandamientos de los Mtodos FormalesResumen y PreguntasNDICEIntroduccin1. Se deber elegir la notacin apropiada2. Se debe formalizar, pero no en exceso3. Se deben estimar los costes4. Se debe tener un experto en mtodos formales5. No se deben abandonar los mtodos de desarrollo tradicionales6. Se debe realizar suficiente documentacin7. No se deben poner en peligro los estndares de calidad8. No ser dogmtico9. Se debe estar en un continuo proceso de prueba. 10. Se debe reutilizarConclusionesPREGUNTAS