12/11/2008

Los diez mandamientos

de los Mtodos Formales

Autoras de GRUPO1:
Luca Nez Anta
DNI: 4444505044445050-B
Mara Gmez Rodrguez
DNI: 44471229
44471229--Q
Romina Carrera Arjolekas DNI: 3616574536165745-Q

Introduccin
y
y

Los Mtodos Formales tcnica para conseguir

sistemas de alta integridad.
integridad
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.
Factores que tendrn gran influencia para saber
si un MF tendr o no xito: Diez mandamientos.
mandamientos

12/11/2008

1. Elegir la notacin apropiada

y
y
y
y

Principal herramienta: lenguaje de especificacin.

Interrelacin entre expresividad del lenguaje y
niveles de abstraccin.
El vocabulario no es la nica tarea a considerar.
Es ms apropiado un proceso algebraico
atendiendo a los aspectos basados en estados
del sistema (CSP, CCS).
N t i bi
Notacin
bien establecida,
t bl id
xito
it asegurado.
d

2. Formalizar, pero no en exceso

y
y
y
y

y
y
y
y

Realmente necesitamos Mtodos Formales?

En algunas
g
reas son mejores
j
los mtodos convencionales ((ejm.:
j
IU).
Aplicar Mtodos Formales a todos los aspectos del sistema,
innecesario y costoso.
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?
Nivel 1: Especificacin Formal.
Nivel 2: Desarrollo/verificacin formal.
formal
Nivel 3: Comprobacin mecnica de pruebas.
Peroel coste est justificado? (sistemas de alta integridad,
prdida de vida humana, gran prdida financiera)

12/11/2008

3. Estimacin de los costes

y

y
y
y

La introduccin inicial de MF puede requerir una

gran inversin.
inversin Sin embargo,
embargo podrn funcionar a
tan bajo costo (o incluso menor) que los
convencionales.
Todava no existen mtricas de especificaciones
formales para estimarlos.
Muchos proyectos de MF en dominios
especializados Poco representativos
especializados.
representativos.
En sistemas de alta integridad, se garantiza la
inversin.

4. Disponer de un experto en MF
y
y

Es muy difcil aprender a usar MF sin ayuda de

un experto.
experto
IBM: realizacin de cursos de capacitacin. Se
convierte en auto-suficiente (no necesita la
ayuda de expertos).
IMNOS: los consultores matemticos y los
ingenieros son separados como fuente de
conocimientos La comunicacin entre los dos
conocimientos.
grupos da el xito asegurado.
Si es necesario se solicita ayuda a una
consultora externa.

12/11/2008

5. No abandonar los mtodos

tradicionales de desarrollo
y
y

Arriesgado sustituir las tcnicas de desarrollo de

software por MF.
MF
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.

Ventaja: se pueden capturar muchos errores

antes de que sea demasiado tarde y caro de
corregir.

6. Documentar suficientemente
y

Muy importante en el diseo del sistema:

Menor ambigedad
Menor probabilidad de errores

Contenido ideal:
Requisitos del sistema
Especificacin formal
Descripcin del lenguaje natural (si procede)

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

12/11/2008

7. No comprometer los estndares

de calidad
y

Los MF son un medio de lograr la mayor

integridad de los sistemas cuando se aplican
adecuadamente.
La organizacin debe asegurarse de que sigue
cumpliendo con sus normas de calidad:
garantizar la adecuada retroalimentacin entre los equipos de
desarrollo y gestin
garantizar la continuidad de la inspeccin de los programas y el
mantenimiento de polticas de pruebas
asegurar que la documentacin del sistema cumple con los estndares
de calidad que se establecieron para los mtodos convencionales de
desarrollo.

Norma de calidad del Software ISO9000.

8. No ser dogmtico
y
y

y
y

Los mtodos formales no son una solucin

universal para cualquier desarrollo informtico.
informtico
Un desarrollo formal no siempre estar libre de
errores (se reducen y son fcilmente
localizables).
No ser suficiente para la implementacin un
desarrollo simple y lineal.
Admitir errores y no tomar pruebas como
definitivas.

12/11/2008

9. Probar, probar y probar otra vez

y

Dijkstra: Las pruebas de los programas pueden

usarse para demostrar la presencia de errores
pero nunca para demostrar su ausencia.
Las pruebas siempre sern un til comprobante
de que un sistema producido formalmente
funciona en el mundo real.
La especificacin inicial ser utilizada para
ayudar a realizar pruebas unitarias en una fase
ms temprana del desarrollo de SW
Reduccin
de costes de mantenimiento del sistema.

10. Reutilizar
y
y

Reutilizar SW reduce costes.

La reutilizacin depender del tipo de sistema
que se est a desarrollar afectando diversos
factores ( tamao de aplicacin, eleccin de
componentes a reutilizar ).
Lenguajes de especificacin formal proporcionan
requisitos del sistema o de componentes de un
sistema no ambiguos
ambiguos, bien documentados y
especificados ideales para ser combinados si
fuera necesario para formar un nuevo sistema.

12/11/2008

CONCLUSIONES
y
y

Decidir que mtodo formal ser ms adecuado a

cada caso.
caso
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.
Reconocer errores y mantener una fase de
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 LOS

MTODOSFORMALES

AutorasGRUPO1:
LucaNezAnta.DNI:44445050B
MaraGmezRodrguez.DNI:44471229Q
RominaCarreraArjolekas.DNI:36165745Q

NDICE

Introduccin..............................................................................................................................3
1.

Sedeberelegirlanotacinapropiada............................................................................3

2.

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

3.

Sedebenestimarloscostes..............................................................................................5

4.

Sedebetenerunexpertoenmtodosformales..............................................................5

5.

Nosedebenabandonarlosmtodosdedesarrollotradicionales...................................6

6.

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

7.

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

8.

Noserdogmtico..............................................................................................................7

9.

Sedebeestarenuncontinuoprocesodeprueba............................................................8

10.

Sedebereutilizar...........................................................................................................9

Conclusiones...........................................................................................................................10
PREGUNTAS.............................................................................................................................11

Introduccin

Los mtodos formales son definidos como una tcnica con la que se consigue, ms
probablemente,sistemasdeunaaltaintegridad.
Desafortunadamente,suusotodavasiguesiendo,mslaexcepcinquelaregla;debido,en
buenaparte,alosgastos,dificultades,etc.
Sinembargo,suusoparaproblemasdelavidareal,estayudandoadestacarelhecho,deque
losproyectosqueempleanmtodosformales,cumplenlosrequisitosestablecidos:entregaa
tiempo, dentro del presupuesto y produciendo un software (y hardware) correcto, bien
estructuradoymantenido.
Hay una serie de factores que pueden tener una gran influencia a la hora de saber si un
proyectodemtodosformalestieneonoxito.
Los mandamientos expuestos a continuacin, se basan en un nmero de proyectos
recientementecompletadosexitosamente.

1. Sedeberelegirlanotacinapropiada

Ellenguajedeespecificacineslaprincipalherramientaenlasetapasinicialesdeldesarrollo
delsistema.Debertenerunassemnticasformalesbiendefinidas.
Paraelegirlanotacin,esnecesariounciertogradodeinterrelacinentrelaexpresividadde
unlenguajedeespecificacinylosnivelesdeabstraccinquesoporta.
Algunos lenguajes pueden tener un vocabulario y construccin extensos para soportar
situaciones particulares; pero nos forzarn a unas implementaciones particulares y mientras
empequeecelasespecificaciones,generalmente,lashacemenosabstractas.
Por otro lado, los lenguajes con vocabularios menos extensos, obtienen grandes
especificaciones,ofreciendoaltosnivelesdeabstraccinyunaimplementacinmspequea.
Elvocabularionoeslanicatareaaconsiderar;porejemplo,intentarespecificarunsistema
concurrente en un lenguaje de especificacin basado en modelos, como Z o VDM, podr
hacerse,peronoeslamejormanera.
EsmsapropiadounprocesoalgebraicocomoCSPoCCS,atendiendoalosaspectosbasados
enestadosdelsistema.
Una notacin bien establecida, con una buena base de usuario, asegurar el xito de la
aplicacinenlasmodificacionesindustriales.

Una parte importante de la aceptacin general de una notacin, es la produccin de un

estndar internacional. Resulta esencial tener un surtido de estndares para garantizar una
uniformidadrazonableyunconjuntodeherramientascompatiblesparasoportarlanotacin.
No debemos conformarnos con una notacin de especificacin estndar, ya que puede ser
msproblemticocomparadoconunlenguajedeprogramacin.

2. Sedebeformalizar,peronoenexceso

Muchas empresas adoptan innecesariamente mtodos formales. Siendo realista, lo primero

que debe determinarse es si realmente se necesitan usar mtodos formales; es decir, si se
desea un incremento de confianza en el sistema, para satisfacer el estndar particular
requerido,paraganarcomplejidad,etc.
Hayreasdondelosmtodosformalesnosontanbuenoscomolosmtodosconvencionales.
En el diseo de la interfaz de usuario, por ejemplo, aunque hubo algunas aplicaciones que
utilizaron tcnicas de especificacin formal con xito, est aceptado que su diseo caiga
dentrodeldominiodelrazonamientoinformal.
Aplicarmtodosformalesatodoslosaspectosdelsistema,podrasertantoinnecesariocomo
costoso.Slounodecadadiezsistemassonobjetodeundesarrolloformal.
Habiendodeterminadoqueunorealmentenecesitalosmtodosformalesyunavezelegidala
notacin apropiada e identificando esos componentes del sistema, uno debe considerar el
nivelenelculvaaemplearlosmtodosformales.
Seidentificantresniveles:
1.Especificacinformal
2.Desarrollo/verificacinformal

3.Pruebasmecnicasdecomprobacin
Cadaunodeestostresnivelesestilensmismo.Sinembargo,hayquedeterminarsielcoste
adicional est justificado. Para sistemas donde se requiere la ms alta integridad, es decir,
donde la prdida de vida humana, una gran prdida financiera o la destruccin masiva de
propiedades, podra ser el resultado del fracaso del sistema; tal inversin podra estar muy
bienjustificadayrequerida!

3. Sedebenestimarloscostes

Laintroduccininicialdelosmtodosformalesenunambientededesarrollo,probablemente
requierecantidadessignificativasdeentrenamiento,laconsultadelcontratoylainversinen
herramientasdeapoyo.
Losmtodosformalespuedenfuncionartanabajocoste(yposiblementeamenorcoste)que
proyectosdesarrolladosusandomtodosconvencionales.
Que los mtodos formales sean ms caros por ellos mismos, es ms bien sintomtico del
hechoquesonusadosensistemascaros,sobretodosirequerimosaltosnivelesdeconfianza
ensucorrectaoperacin.
Sehanaplicadoanmtodosformalesaunnmerosuficientedeproyectosparadeterminar
las tendencias y muchos proyectos con mtodos formales estn en dominios muy
especializados, poco probables de ser tratados muy regularmente, por tanto son poco
representativos.
Aunquenoseafirmequelosmtodosformalessonbaratos;slosernparasistemasdealta
integridaddondesegaranticelainversin.
Eltiempoesunpuntodecomienzotilparaextenderlosmodelosexistentes,contalquenos
permitasuficientesmrgenesdeerror.

4. Sedebetenerunexpertoenmtodosformales

La mayora de proyectos exitosos realizados utilizando mtodos formales han accedido al

menos a un consultor experto en el uso de tcnicas formales. Es muy difcil aprender a usar
mtodosformalessinayudadeunexperto.
En el caso de IBM se han realizado cursos de capacitacin y poco a poco un significante
nmerodepersonasadquirieronfluidezenlaaplicacindetcnicasformales.As,finalmente
IBMseconvirtienautosuficienterespectoalusodemtodosformales,yaquenonecesita
ayudacontinuadeexpertosexternos.
EnINMOSfueadoptadounenfoquediferente.Enestecaso,losconsultoresmatemticosylos
ingenierossonseparadoscomofuentedeconocimientos.Sinembargo,lacomunicacinentre
losdosgruposdaelxitoasegurado,amenosquelosmatemticosylosingenierosnopuedan
apreciar la funcin y problemas de los dems, ya que en este caso el xito ser difcil de
alcanzar. Cuando se considera necesario, se solicita ayuda a una consultora externa para
solucionarproblemasespecficos.

5. Nosedebenabandonarlosmtodosdedesarrollo
tradicionales

Existeunaconsiderableinversinenlastcnicasdedesarrollodesoftwareyseraarriesgado
sustituir estos por mtodos formales. En su lugar, es conveniente integrar los mtodos
formalesenelprocesodediseoenfuncindeloscostosefectivos.Unamaneradehacerloes
investigarcmounmtodoformalyaexistentesepuedecombinardemaneraefectivaconun
mtodoestructuradoexistenteyyaenusoenlaindustria(porejemploelmtodoSAZ,quees
unacombinacindeSSADMyZ).
Lo ideal sera la combinacin de los dos mtodos, obtenindose as la mayora de los
beneficiosoventajasdeambos,comoporejemplolamayorprecisinenlaespecificacinque
ofrecenlosmtodosformalesymejorpresentacinparaunapersonanoexpertaqueofrecen
losmtodosestructurados.
Otraalternativaalaintegracindeambastcnicaseselusodemtodosformalespararevisar
unprocesoyaexistente.Paraproporcionarinformacinaunequipodediseopuedenusarse
los mtodos tradicionales de desarrollo teniendo un equipo de anlisis separado de los
principiosdeespecificacinformalenelprocesodediseo,porlotanto,sepuedencapturar
muchoserroresantesdequeseademasiadotardeycarodecorregir.EstosehaaplicadoenZ
conmuchoxitoenfuncindeloscostosefectivos.
Otro ejemplo es Cleanroom, una tcnica que podra incorporar el uso de las notaciones
formales. Esta tcnica se ha aplicado con mucho xito utilizando tcnicas de desarrollo de
software con un historial demostrado de reducir errores, para el resultado de aplicaciones
segurasynocrticas.Siseencuentrandemasiadoserrores,debersermodificadoelproceso
antesqueelprograma.
Desde el punto de vista del lenguaje, los programas reales son demasiado grandes para ser
probadosdemaneracorrecta,porloquedebenserescritoscorrectamenteenprimerlugar.A
vecesesposiblecombinardiferentesmtodosformalestilesyefectivos,comoporejemplo
HOL,queha sidoutilizadoparaproporcionarherramienta deapoyoaZ,locualpermite que
sea ms legible y aumenta la confianza en el desarrollo debido a las pruebas mecnicas
chequeadasporHOL.

6. Sedeberealizarsuficientedocumentacin

La documentacin es una parte muy importante en el diseo del sistema, ya que conduce a
una menor ambigedad y por lo tanto menos probabilidad de errores. En el caso de la
seguridaddelossistemascrticos,losproblemasdetiemposeconviertenensignificativosylos
mtodosparadocumentarlossonespecialmenteimportantes.

Lo ideal sera que la documentacin del sistema contuviese los requisitos y la especificacin
del sistema en una notacin formal adecuada y acompaada, cuando proceda, de la
descripcindellenguajenatural.
En general, es muy recomendable producir una especificacin informal y al mismo tiempo
explicarladescripcinformal.Sihayalgunadiscrepanciaentrelosdos,laespecificacinformal
debe ser tomada como el elemento final de la documentacin ya que este es el menos
ambiguodelasdosdescripciones.

7. Nosedebenponerenpeligrolosestndaresdecalidad

Hasta hace poco tiempo, apenas han existido estndares que estuvieran pensados
especficamenteenelsoftwaredondesepuedenaplicarmtodosformales,comoporejemplo
laseguridadenlossistemascrticos.
UnadelasnormasdecalidaddesoftwareeslaISO9000,quesepuedenaplicarencualquier
tipodeorganizacinqueestorientadaalaproduccindebienesoservicios.Secomponende
estndares y herramientas especficas como los mtodos de auditoria para verificar que los
sistemasdegestincumplenconelestndar.Suimplantacinunagrancantidaddeventajas
paralasempresascomomejorarlasatisfaccindelcliente,mejorarlosprocesosrelacionados
conlacalidad,reduccindeincidenciasenlaproduccinoaumentodelaproductividad.
Errneamentelosdesarrolladorespuedenverenlaaplicacindemtodosformalesunmedio
paraelcorrectodesarrollodesoftware,siendostos,porelcontrario,unmediodelograrla
mayor integridad de los sistemas cuando se aplican adecuadamente. A pesar de todo, la
organizacin debe asegurarse de que sigue cumpliendo con sus normas de calidad. Esto
incluye garantizar la adecuada retroalimentacin entre los equipos de desarrollo y gestin,
garantizarlacontinuidaddelainspeccindelosprogramasyelmantenimientodepolticasde
pruebas,ascomoasegurarqueladocumentacindelsistemacumpleconlosestndaresde
calidadqueseestablecieronparalosmtodosconvencionalesdedesarrollo.

8. Noserdogmtico

Con este mandamiento se quiere expresar que los mtodos formales no son una solucin
universal a cualquier desarrollo informtico. El usarlos o no, y saber cul es la notacin
correcta para un desarrollo depende de las caractersticas del sistema a implementar. Por
ejemplo,sehademostradoqueestaseriedetcnicassonespecialmentetilesensistemasde
informacincrtica,esdecirendesarrollosdondelaintegridadesvital.
Pero,estonoquieredecirque,haciendousodeestastcnicasunaaplicacinsoftware:
7

Estar completamente libre de errores; se asegura que usando mtodos

formales,loserroressereducenconsiderablementeysonmasfcilmente
localizablesduranteeldesarrollodeunaaplicacin,peronogarantizansu
ausencia.

Acausadelprimermotivonosersuficienteundesarrollosimple,lineal;
con mtodos formales al igual que con mtodos convencionales ser
necesarialapresenciadeunacontinuafaseiterativaduranteeldesarrollo
delsoftware.

Portanto,enestemandamientosetratadeconcienciaraldesarrolladordelaimportanciade
admitir los errores que pueden surgir usando mtodos formales, como por ejemplo, no
escoger un nivel de abstraccin adecuado para una especificacin y de concienciarlo de no
tomarpruebascomodefinitivasporelsimplehechodeacabarunafasedeldesarrollo.

9. Sedebeestarenuncontinuoprocesodeprueba.

AqutenemosunacitadelDijkstraquedice: Laspruebasdeprogramaspuedenusarsepara
demostrarlapresenciadeunerrorperonuncaparademostrarsuausencia
Conestoloquequieredeciresquemientrashayapresenciadeerrores,laspruebasnuncahan
dedesaparecer.
Laingenieradelsoftwareesuntrabajorealizadoporpersonas,locualvaaimplicarqueenel
desarrollodeunaaplicacinhayapresenciadeerroresdebidoanuestrahabilidadinnatapara
provocarlos. Por lo tanto, no debemos subestimar la fiabilidad humana, y las pruebas que
vayamos haciendo siempre sern un til comprobante de que un sistema producido
formalmentefuncionaenelmundoreal.
En este tema es dnde los mtodos formales adquieren mayor importancia ya que ofrecen
ventajas considerables, como es que nos permiten verificar que la implementacin se
correspondeconlaespecificacininicial.
Portanto,laespecificacininicialserutilizadaparaayudararealizarlaspruebasunitariasen
una fase ms temprana del desarrollo del software, para as poder reducir los costes de
mantenimientodelsistema.
Pero hay que tener en cuenta que, a pesar de que nos aporten una mayor confianza en la
integridaddelsistemayunamayorconfianzaenqueelsistemafuncionacomoenunprincipio
seesperaba,stosnogarantizanenunaimplementacinunaabsolutacorreccin.

10.

Sedebereutilizar

Todos sabemos que en los sistemas llevados a cabo mediante mtodos convencionales est
ms que comprobado que la reutilizacin de software, incluyendo cdigo, especificaciones,
diseo y documentacin ayuda a disminuir considerablemente el conjunto de costes del
desarrollo.Puesbien,enundesarrolloformalocurreexactamentelomismopudiendoreducir
costestantoenherramientascomoenformacin.
Esta reutilizacin depender del tipo de sistema que se est a desarrollar afectando entre
otrosmotivoslossiguientes:

Eltamaodeaplicacin;cuantomsgrandesealaaplicacinmsespecializadasery
porlotantomasdifcilsersureutilizacin.
Laeleccindequcomponentessonmsadecuadosparaincluirenlalibreraparasu
posteriorreutilizacinolaconfianzaquetenemosonodeesoscomponentes.

Elusodelosmtodosformaleseneldesarrollodelsistemacontribuyealaventajadereutilizar
elsoftware,yaqueloslenguajesdeespecificacinformalproporcionarunmediodeestado
noambiguodelosrequisitosdeunsistema,odelcomponentedeunsistema.
As pues, se podrn identificar los componentes que han sido formalmente especificados y
suficientementebiendocumentados,reutilizadosycombinadosparaformarloscomponentes
delnuevosistema.
Por tanto, los problemas con los diversos componentes que forman parte de una librera
disminuyen, aumentando la confianza en la integridad de los componentes, ya que cada
componente esclaramenteespecificado,ypuedetenerdiferentespropiedadespropuestasy
demostradas.

Conclusiones

Paragarantizarelxitodelaaplicacindemtodosformalesenuncontextoindustrialhabr
quedecidirantesdenadaquemtodoformalsermsadecuadoacadacaso.
Por tanto se ha de escoger la notacin apropiada que mejor se ajuste a los procesos de
desarrollo de la aplicacin determinada, intentado siempre garantizar que estas pautas y
procedimientos se mantengan en la medida de lo posible para obtener el xito de la
industrializacindelosMFS.
Hayque teneren cuentaque laIngenieradel Softwareesuna actividad humanaquenunca
estar libre de errores ya sea desarrollada por medio de un mtodo formal como
convencional,porloquesiempretendrqueexistirunafasedepruebasiterativacomoeluso
adecuadodeherramientasautomatizadas,paraobtenerelxitodesistemasdealtaintegridad
usandomtodosformales.

10

PREGUNTAS

Qupodemoslograrutilizandomtodosformales?

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

obligatoriamenteporusarmtodosformales).

Unamayorintegridaddelossistemascuandoseaplicanadecuadamente.

Disminuir el coste del proyecto. (Falso, algunas veces el coste es menor que en un
desarrolloutilizandomtodosconvencionales,yotrasvecesestecosteessuperior).

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

Qupuntosfundamentalesdebetenerunabuenadocumentacin?

Ladescripcindellenguajenatural.(Falso,noesunarespuestacompleta,yademsno
siempreesimportanteincluirladescripcindellenguajenaturalenladocumentacin).

Ladescripcindelestndardecalidadusado.(Falso,dependedeltipodeproyectoyno
esunfactorimportanteparaunabuenadocumentacin).

Los requisitos, la especificacin del sistema y la descripcin del lenguaje natural, si

procede.

El nivel en el cul se han empleado los mtodos formales. (Falso, ya que esta
informacinesnecesariaparapoderemplearmtodosformalesperonopararealizar
unabuenadocumentacin).

Cundosedeberanutilizarlosmtodosformales?
-

Siempre, porque aunque los costes sean altos, los mtodos formales harn que
nuestro proyecto sea ms fiable y comprensible. (Falso, ya que en el diseo de la
interfaz de usuario, por ejemplo, es mejor el uso de especificaciones informales.
Ademsaplicarlosmtodosformalesatodoslosaspectosdelsistema,puedesertanto
innecesario como costoso. Por otro lado, dependiendo del tipo de proyecto a
desarrollar,loscostespuedenserigualesomenoresqueconmtodosconvencionales).

Slocuandoserequieralamsaltaintegridad,yaquelosmtodosformalessonuna
tcnicaparaconseguirlo.
11

Debenutilizarseenproyectosdondelaprdidadevidahumana,prdidafinancierao
la destruccin masiva de propiedades, provoque un fracaso del sistema; pero nunca
para incrementar la confianza en el sistema, ganar complejidad o satisfacer un
estndar,yaqueesungastoinnecesario.(Falso,porquetodaslasopcionessonbuenas
razonesparautilizarlosyjustificansugasto).

No se deben utilizar nunca. (Falso, ya se han dado razones ms que suficientes que
justificansuusoyportantoestarespuestacarecedesentido).

Quhacequeunproyectodemtodosformalestengaxito?
-

Escogerelmtodoformalmsadecuadoyseguirunaseriedefactores(comoelegirla
notacinadecuada,estimarcostes,etc.).

Seguir los mandamientos al pie de la letra. (Falso, ya que en algunos casos puede
resultartantoinnecesariocomocostoso).

Esunapreguntamuysubjetivaquenosepuederesponder.(Falso,yaqueapesarde
serunapreguntasubjetiva,sepuederesponder).

Tenerunexpertoenmtodosformalesesloniconecesarioparatenerunproyecto
exitoso.(Falso,yaqueesunadelascosasnecesarias,peronolanica).

Quimplicanlosmtodosformales?
-

Larenunciaalusodelosmtodostradicionalesdediseo.(Falso,yaqueelusodelos
mtodosformalesdependerdeltipodeaplicacinaimplementar).

La perfeccin del software haciendo innecesaria su verificacin. (Falso, el uso de

mtodos formales reduce considerablemente la presencia de errores y ayuda a
encontrarlosmsfcilmente,peronogarantizasuausencia).

Unaumento enloscostesde desarrollo.(Falso, elcostededesarrollopuedellegar a

sermsreducidoqueusandomtodosconvencionales).

Altaintegridadenaplicacionesquelorequieren.

12