<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"	>
<channel>
	<title>Comments on: Complejidad ciclomática, o la métrica esencial para evaluar el diseño software</title>
	<atom:link href="http://www.javiergarzas.com/2007/10/complejidad-ciclomtica-o-la-mtrica.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.javiergarzas.com/2007/10/complejidad-ciclomtica-o-la-mtrica.html</link>
	<description></description>
	<lastBuildDate>Tue, 07 Feb 2012 11:50:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: ouafae</title>
		<link>http://www.javiergarzas.com/2007/10/complejidad-ciclomtica-o-la-mtrica.html/comment-page-1#comment-7</link>
		<dc:creator>ouafae</dc:creator>
		<pubDate>Sun, 04 Nov 2007 10:21:00 +0000</pubDate>
		<guid isPermaLink="false">http://kybeleconsulting.com/javiergarzas/?p=20#comment-7</guid>
		<description>La complejidad ciclomatica es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.&lt;br/&gt;El valor calculado como complejidad ciclomatica define el numero de caminos independientes del conjunto básico de un programa y nos da un limite superior para el numero de pruebas que se deben  realizar para asegurar que se ejecuta cada sentencia al menos una vez.&lt;br/&gt;1. V (G) = a - n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.&lt;br/&gt;2. V (G) = r, siendo r el número de regiones cerradas del grafo.&lt;br/&gt;3. V (G) = c + 1, siendo c el número de nodos de condición.&lt;br/&gt;&lt;br/&gt;&lt;br/&gt;En mi opinión, veo que las pruebas son una de las etapas más importantes de la vida del software, no sólo porque se comprueba el correcto funcionamiento del sistema, sino  porque es un mecanismo que ayuda al programador a saber si el sistema que ha realizado satisface las necesidades del usuario.&lt;br/&gt;La fase de pruebas se considera una de las fases más difíciles sin embargo la mayoría de los programadores no le dan la importancia y no lo realizan de la forma adecuada.&lt;br/&gt;&lt;br/&gt;El problema es en los sistemas que necesitan muchos casos de prueba para ejecutarse por ejemplo los sistemas de la NASA, los sistemas de aviones representan casos especiales donde debemos tener una certeza segura de la validez del programa, es en este tipo de aplicaciones donde las pruebas del software representan un factor fundamental para asegurar el correcto funcionamiento para cualquier situación.&lt;br/&gt;En mi punto de vista, veo que la mejor forma de comprobar el software es crear además del sistema un programa que compruebe el propio sistema y así se facilite al programador la tarea que le considere difícil y aburrida,&lt;br/&gt;Este programa que el programador va a crear ejecutara los diferentes casos de prueba del sistema y sacara los diferentes  errores que han ocurrido, en que sentencia, en que caso, etc...&lt;br/&gt;Y veo también útil utilizar las verificaciones formales que se usan paralelamente al desarrollo del software. El sistema formal de HOARE es un mecanismo que se aplica al programa que consta de una precondición P, una instrucción simple o compuesta (programa) S y una poscondición Q. P y Q son afirmaciones sobre los estados de programa.&lt;br/&gt;&lt;br/&gt;Normalmente el equipo de desarrollo del proyecto se encuentra presionado por la necesidad de cumplir con las fechas establecidas y el proceso de pruebas no se cumple o se ejecuta de una manera desorganizada, sin método y sin considerar los tiempos establecidos para esta fase. El resultado es un software sin las pruebas mínimas requeridas y sin el nivel de calidad esperado.&lt;br/&gt;Otra solución será contar con un grupo externo especializado en procesos de aseguramiento de calidad y específicamente en pruebas de software, que por medio de un método establecido y maduro, sin presiones políticas propias de la organización, pueda ayudar a alcanzar el nivel de calidad esperado del software y alcanzar el éxito del proyecto.&lt;br/&gt;&lt;br/&gt;Entonces el aseguramiento de la calidad del software cada vez se convierte a una necesidad  porque cada vez los errores en el software afectan de manera directa o indirecta en graves consecuencias para la organización.&lt;br/&gt;Ouafae</description>
		<content:encoded><![CDATA[<p>La complejidad ciclomatica es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.<br />El valor calculado como complejidad ciclomatica define el numero de caminos independientes del conjunto básico de un programa y nos da un limite superior para el numero de pruebas que se deben  realizar para asegurar que se ejecuta cada sentencia al menos una vez.<br />1. V (G) = a &#8211; n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.<br />2. V (G) = r, siendo r el número de regiones cerradas del grafo.<br />3. V (G) = c + 1, siendo c el número de nodos de condición.</p>
<p>En mi opinión, veo que las pruebas son una de las etapas más importantes de la vida del software, no sólo porque se comprueba el correcto funcionamiento del sistema, sino  porque es un mecanismo que ayuda al programador a saber si el sistema que ha realizado satisface las necesidades del usuario.<br />La fase de pruebas se considera una de las fases más difíciles sin embargo la mayoría de los programadores no le dan la importancia y no lo realizan de la forma adecuada.</p>
<p>El problema es en los sistemas que necesitan muchos casos de prueba para ejecutarse por ejemplo los sistemas de la NASA, los sistemas de aviones representan casos especiales donde debemos tener una certeza segura de la validez del programa, es en este tipo de aplicaciones donde las pruebas del software representan un factor fundamental para asegurar el correcto funcionamiento para cualquier situación.<br />En mi punto de vista, veo que la mejor forma de comprobar el software es crear además del sistema un programa que compruebe el propio sistema y así se facilite al programador la tarea que le considere difícil y aburrida,<br />Este programa que el programador va a crear ejecutara los diferentes casos de prueba del sistema y sacara los diferentes  errores que han ocurrido, en que sentencia, en que caso, etc&#8230;<br />Y veo también útil utilizar las verificaciones formales que se usan paralelamente al desarrollo del software. El sistema formal de HOARE es un mecanismo que se aplica al programa que consta de una precondición P, una instrucción simple o compuesta (programa) S y una poscondición Q. P y Q son afirmaciones sobre los estados de programa.</p>
<p>Normalmente el equipo de desarrollo del proyecto se encuentra presionado por la necesidad de cumplir con las fechas establecidas y el proceso de pruebas no se cumple o se ejecuta de una manera desorganizada, sin método y sin considerar los tiempos establecidos para esta fase. El resultado es un software sin las pruebas mínimas requeridas y sin el nivel de calidad esperado.<br />Otra solución será contar con un grupo externo especializado en procesos de aseguramiento de calidad y específicamente en pruebas de software, que por medio de un método establecido y maduro, sin presiones políticas propias de la organización, pueda ayudar a alcanzar el nivel de calidad esperado del software y alcanzar el éxito del proyecto.</p>
<p>Entonces el aseguramiento de la calidad del software cada vez se convierte a una necesidad  porque cada vez los errores en el software afectan de manera directa o indirecta en graves consecuencias para la organización.<br />Ouafae</p>
]]></content:encoded>
	</item>
</channel>
</rss>

