Mapa conceptual Hacking Ético

Garantía de calidad estadística

La garantía de calidad estadística refleja una tendencia, creciente en toda la industria, a establecer la calidad más cuantitativamente. Para el software, la garantía de calidad estadística implica los siguientes pasos:

1. Se agrupa y se clasifica la información sobre los defectos del software.
2. Se intenta encontrar la causa subyacente de cada defecto.
3. Mediante el principio de Pareto (el 80% de los defectos se pueden encontrar en el 20% de todas las posibles causas), se aísla el 20 %(los ”pocos vitales”).
4. Una vez que se han identificado los defectos vitales, se actúa para corregir los problemas que han producido los defectos.

Para ilustrar el proceso, supongamos que una organización de desarrollo de software recoge información sobre defectos durante un período de un año. Algunos de los defectos se descubren mientras se desarrolla el software. Otros se encuentran después de que el software se haya distribuido al usuario final. Aunque se descubren cientos de errores diferentes, todos se pueden encontrar en una (o más) de las siguientes causas:

• Especificación incompleta o errónea (EIE).
• Mala interpretación de la comunicación del cliente (MCC).
• Desviación deliberada de la especificación (DDE).
• Incumplimiento de los estándares de programación (IEP).
• Error en la representación de los datos (ERD).
• Interfaz de módulo inconsistente (IMI).
• Error en la lógica de diseño (ELD).
• Prueba incompleta o errónea (PIE).
• Documentación imprecisa o incompleta (DII).
• Error en la traducción del diseño al lenguaje de programación (TLP).
• Interfaz hombre-máquina ambigua o inconsistente (IHM).
• Varios (VAR).

 

 

Para aplicar la SQA estadística se construye la Tabla:

 

La tabla indica que EIE, MCC y ERD son las causas vitales que contabilizan el 53 por 100 de todos los errores. Sin embargo, debe observarse que si sólo se consideraran errores serios, se seleccionarían las siguientes causas vitales: EIE, ERD, TLP y ELD. Una vez determinadas las causas vitales, la organización de desarrollo de software puede comenzar la acción correctiva. Por ejemplo, para corregir la MCC, el equipo de desarrollo del software podría implementar técnicas que facilitaran la especificación de la aplicación para mejorar la calidad de la especificación y la comunicación con el cliente. Para mejorar el ERD, el equipo de desarrollo del software podría adquirir herramientas CASE para la modelización de datos y realizar revisiones del diseño de datos más rigurosas.

Después del análisis, el diseño, la codificación, la prueba y la entrega, se recopilan los siguientes datos:

Ei = número total de defectos descubiertos durante la etapa i-ésima del proceso de ingeniería del software;

Si = número de defectos graves;

Mi =número de defectos moderados;

Tj = número de defectos leves;

PS =tamaño del producto (LDC, sentencias de diseño, páginas de documentación) en la etapa i-ésima.

W_s , W,,, , W_t = factores de peso de errores graves, moderados, y leves, en donde los valores recomendados son W_s = 10, W,,, = 3, W_t = 1. Los factores de peso de cada fase deberían agrandarse a medida que el desarrollo evoluciona. Esto favorece a la organización que encuentra los errores al principio.

En cada etapa del proceso de ingeniería del software se calcula un índice de fase, lF_i :

lF_i = W_s (S_i,/E_i) +W_m (M_ii E_i) + W_t (T_i /E_i)

El índice de errores (IE) se obtiene mediante el cálculo del defecto acumulativo de cada IFi, asignando más peso a los errores encontrados más tarde en el proceso de ingeniería del software, que a los que se encuentran en las primeras etapas:

IE =∑ (i x IF,) / PS

= (IF, + 2IF₂+ 3IF₃+ … iIF_i) / PS

Se puede utilizar el índice de errores junto con la información recogida en la Tabla 8.1, para desarrollar una indicación global de la mejora en la calidad del software.

Tal y como dice Pressman la SQA estadística se puede resumir en: “¡Utilizar el tiempo para centrarse en cosas que realmente interesan, pero primero asegurarse que se entiende qué es lo que realmente interesa!”

 

Fuente: Ingeniería del Software. Un enfoque práctico, Roger S. Pressman adaptado por Darrel Ince

Garantía de Calidad del software

El software de alta calidad es una meta importante para cualquier desarrollador.

La calidad del software la podemos definir de la siguiente forma:

“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

Con la definición anteriormente descrita se puede hacer hincapié en tres puntos muy importantes:

1. Los requisitos del software son la base de las medidas de la calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software.
3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan. SE debe tener muy en cuenta esto ya que si el software se ajusta a los requisitos explícitos pero no a los implícitos, la calidad del software disminuye notablemente.

Problemas de fondo

La historia de la garantía de calidad en el desarrollo de software es paralela a la historia de la calidad en la creación de hardware. Durante los años cincuenta y sesenta la calidad era responsabilidad únicamente del programador. Durante los años setenta se introdujeron estándares de garantía de calidad para el software en los contratos militares y se han extendido rápidamente a los desarrollos de software en el mundo comercial [IEE94].

La garantía de calidad del software (SQA) es un patrón de acciones planificado y sistemático que se requiere para asegurar la calidad del software.

El grupo de SQA sirve como representación del cliente en casa, es decir, la gente que lleva a cabo la SQA debe mirar el software desde el punto de vista del cliente.

Actividades de SQA

La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes; los ingenieros de software que realizan trabajo técnico y un grupo de SQA que tiene la responsabilidad de la Planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes.

Los ingenieros de software afrontan la calidad aplicando métodos técnicos, sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas de software bien planificadas.

Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad

Actividades que realiza un grupo independiente de SQA:

• Establecimiento de un plan de SQA para un proyecto.
• Participación en el desarrollo de la descripción del proceso de software del proyecto.
• Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido.
• Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software.
• Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido.
• Registrar lo que no se ajuste a los requisitos e informar a sus superiores.

La Tendencia de la Calidad

La alta calidad del producto se traduce en ahorro de coste y en una mejora general. La tendencia de la calidad comenzó en los años cuarenta con el influyente trabajo de W. Edwards Deming [DEM86], y se hizo la primera verificación en Japón.

Los japoneses han desarrollado un enfoque sistemático para la eliminación de las causas raíz de defectos en productos. A lo largo de los años setenta y ochenta se le llama “Gestión Total de Calidad (GTC)”. Aunque la terminología difiere según los diferentes países y autores, normalmente se encuentra cuatro pasos que constituyen el fundamento de cualquier programa de GTC:

1. El primer paso se llama kuizeny se refiere a una mejora continua del proceso. El objetivo es desarrollar un proceso que sea visible, repetible y mensurable.
2. Una vez que se ha alcanzado el kuizenel siguiente paso se llama aturimaehinshitsu. Este paso examina lo intangible que afecta al proceso y trabaja para optimizar su impacto en el proceso.
3. El siguiente paso llamado kansei (traducido como “los cinco sentidos”) se centra en el usuario del producto (en este caso, software). Kansei conduce a la mejora en el producto mismo, y potencialmente al proceso que lo creó.
4. Finalmente el paso llamado miryokutekihinshitsu amplía la preocupación de la gestión más allá del producto inmediato. Este es un paso orientado a la gestión que busca la oportunidad en áreas relacionadas que se pueden identificar observando la utilización del producto en el mercado.

La mayoría de las compañías debería preocuparse inmediatamente por kuizen, hasta que hayan logrado un proceso de software avanzado, para luego preocuparse por los siguientes pasos.



 

El Estándar de Calidad ISO 9001

La norma ISO 9001, es un método de trabajo, que se considera tan bueno, Que es el mejor para mejorar la calidad y satisfacción de cara al consumidor. La versión actual, es del año 2008, que ha sido adoptada como modelo a seguir para obtener la certificación de calidad. Y es a lo que tiende, y debe de aspirar toda empresa competitiva, que quiera permanecer y sobrevivir en el exigente mercado actual.

Estos principios básicos de la gestión de la calidad, son reglas de carácter social encaminadas a mejorar la marcha y funcionamiento de una organización mediante la mejora de sus relaciones internas. Estas normas, han de combinarse con los principios técnicos para conseguir una mejora de la satisfacción del consumidor.

Certificación en gestión de la calidad

La certificación en la norma_9001, es un documento con validad legal, expedido por una entidad acredita. Y que certifica, que usted cumple las más estrictas normas de excelencia, en aras a un mejora de la satisfacción del cliente.

Hay dos tipos de certificaciones, de empresa y de producto. Estas últimas, solo tienen en cuenta la cualidad técnica del producto. Y no la satisfacción del cliente, de la que se ocuparía la certificación de empresa. Si una empresa está certificada, todos sus productos lo están.

Nosotros, solo vamos a hablar de la filosofía y principios de aplicación. No trataremos todo el contenido de la norma. Solo de los puntos que corresponden a la metodología de la especificación. Que decíamos quiere mejorar potenciando y mejorando la organización encargada de la producción.

 

Los 8 Principios básicos de la gestión de la calidad o excelencia

1. Organización enfocada a los clientes
   Organización enfocada a los clientes
   las organizaciones dependen de sus clientes y por lo tanto comprender sus necesidades presentes y futuras, cumplir con sus requisitos y esforzarse en exceder sus expectativas.
2. Liderazgo
   Liderazgo
   Los lideres establecen la unidad de propósito y dirección de la organización. Ellos deben crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente para lograr los objetivos de la organización.
3. Compromiso de todo el personal
   Compromiso de todo el personal
   El personal, con independencia del nivel de al organización en el que se encuentre, es la esencia de la organización y su total implicación posibilita que sus capacidades sean usadas para el beneficio de la organización.
4. Enfoque a procesos
   Enfoque a procesos
   Los resultados deseados se alcanzan más eficientemente cuando los recursos y las actividades relacionadas se gestionan como un proceso.
5. Enfoque del sistema hacia la gestión
   Enfoque del sistema hacia la gestión
   Identificar, entender y gestionar un sistema de procesos interrelacionados para un objeto dado, mejora la eficiencia y la eficiencia de una organización.
6. La mejora continua
   La mejora continua
   la mejora continua debería ser el objetivo permanente de la organización.
7. Enfoque objetivo hacia la toma de decisiones
   Enfoque objetivo hacia la toma de decisiones
   Las decisiones efectivas se basan en el análisis de datos y en la información.
8. Relaciones mutuamente beneficiosas con los proveedores

Relaciones mutuamente beneficiosas con los proveedores
Una organización y sus proveedores son independientes y una relación mutuamente benéfica intensifica la capacidad de ambos para crear valor y riqueza.

 

Sellos de certificación

 

Webgrafía.

http://www.buscarportal.com/articulos/iso_9001_gestion_calidad.html

Pruebas del software

Caja Negra

Las pruebas de caja negra se denominan también pruebas funcionales, consisten en suministrar datos de entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el programa por dentro.

Las pruebas de caja negra están especialmente indicadas para probar el programa en lo que se refiere a la interfaz de usuario.

CASO DE PRUEBA	Calculo de estimación de costo utilizando COCOMO básico
PROPÓSITO	Calcular el esfuerzo, tiempo y el número de personas para realizar un proyecto utilizando COCOMO básico
PREREQUISITOS	Ejecutar aplicación
DATOS DE ENTRADA	Dar valor al cuestionario de preguntas Número de entradas Número de salidas Número de peticiones Número de archivos Dispositivos externos Líneas de código Valor a pagar a cada programador
PASOS	Ingresar número de entradas = 7, salidas = 7, peticiones = 5, archivos = 6 y dispositivos externos = 3. Seleccionar el factor de peso = medio Seleccionar el modelo del cocomo básico = semiacoplado Ingresar líneas de código = 100 Ingresar el valor a pagar a cada programador = 150.50 Asignar el valor a cada pregunta del cuestionario = 3, 3, 3, 2, 4, 5, 4, 5, 4, 4, 3, 2, 1, 1 Dar click en [Aceptar]
RESULTADOS	ü  Factores Fi = 44 ü  Puntos de Fusión = 131.89 ü  Kilo líneas de código =  13.19 ü  Esfuerzo = 53.92 personas/mes ü  Tiempo de desarrollo = 10.09 meses ü  Número de personas total = 5.34 personas ü  Costo total del proyecto = 803.97 dólares

Las entradas se ingresaron como se indica en la siguiente figura:

Las salidas generadas son las siguientes:

El programa genera las salidas esperadas y no acepta campos vacíos, ni valores no válidos, de manera general funciona de manera óptima pero necesariamente necesita mejoras.

Integración incremental

Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo. La prueba no se puede realizar ya que contiene un solo módulo.

Prueba de integración

Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. La prueba no se puede realizar ya que contiene un solo módulo.

Prueba de fin a fin

Es similar a la prueba de sistema pero esta involucra la interacción con otro hardware, bases de datos y redes. La prueba no se puede ya que no necesita base de datos ni hardware adicional.

Prueba de sanidad

Determina si la nueva versión de un software está bien realizada y si necesita un nuevo esfuerzo en la prueba de software. La prueba no se puede realizar ya que es la primera versión.

Webgrafia:

• http://www.slideshare.net/dajigar/presentacion-pruebas-presentation
• http://www.galeon.com/neoprogramadores/met_test.htm

Subversion

¿Qué es?

Subversion es un sistema de control de versiones libre y de código fuente abierto. Es decir, Subversion maneja ficheros y directorios a través del tiempo. Hay un árbol de ficheros en un repositorio central. El repositorio es como un servidor de ficheros ordinario, excepto porque recuerda todos los cambios hechos a sus ficheros y directorios. Esto le permite recuperar versiones antiguas de sus datos, o examinar el historial de cambios de los mismos. En este aspecto, mucha gente piensa en los sistemas de versiones como en una especie de “máquina del tiempo”.

Algunos sistemas de control de versiones son también sistemas de administración de configuración de software. Estos sistemas son diseñados específicamente para la administración de árboles de código fuente, y tienen muchas características que son específicas del desarrollo de software— tales como el entendimiento nativo de lenguajes de programación, o el suministro de herramientas para la construcción de software. Sin embargo, Subversion no es uno de estos sistemas. Subversion es un sistema general que puede ser usado para administrar cualquier conjunto de ficheros. Para usted, esos ficheros pueden ser código fuente— para otros, cualquier cosa desde la lista de la compra de comestibles hasta combinaciones de vídeo digital y más allá.

Subversion no es un sistema de gestión de la configuración pero es posible implementar sobre Subversion buenas prácticas de gestión de la configuración utilizando la estructura habitual de Subversion, sin embargo no existe un sistema automático para obligar a que se cumplan.

 

La estructura habitual de un repositorio de Subversion es:

• Trunk: desarrollo principal.
• Tags: ubicación de las versiones congeladas.
• Branches: ubicación con versiones de desarrollo paralelas al trunk.

 

 

 

¿Cómo funciona?

Subversion puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que se encuentran en distintos ordenadores. A cierto nivel, la capacidad para que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboración. Se puede progresar mas rápidamente sin un único conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para temer por que la calidad del mismo vaya a verse afectada por la pérdida de ese conducto único—si se ha hecho un cambio incorrecto a los datos, simplemente deshaga ese cambio.

 

Ventajas

• Se sigue la historia de los archivos y directorios a través de copias y renombrados.
• Las modificaciones (incluyendo cambios a varios archivos) son atómicas.
• Se envían sólo las diferencias en ambas direcciones (en CVS siempre se envían al servidor archivos completos).
• Permite selectivamente el bloqueo de archivos. Se usa en archivos binarios que, al no poder fusionarse fácilmente, conviene que no sean editados por más de una persona a la vez.
• Cuando se usa integrado a Apache permite utilizar todas las opciones que este servidor provee a la hora de autentificar archivos (SQL, LDAP, PAM).
• Consume pocos recursos.

 

Desventajas

• La principal desventaja de Subversion es que es más lento que CVS y que una verificación local de Subversion requiere mayor espacio en disco.
• El manejo de cambio de nombres de archivos no es completo. Lo maneja como la suma de una operación de copia y una de borrado.
• El manejo de archivos binarios los trata internamente como si fuera de texto no como de Subversion.

 

 

 

¿Cómo instalarlo?

Subversion está construido sobre una capa de portabilidad llamada APR (la biblioteca Apache Portable Runtime), lo cual significa que Subversion debería funcionar en cualquier sistema operativo donde lo haga el servidor httpd Apache: Windows, Linux, todos los sabores de BSD, Mac OS X, Netware y otros.

La manera más sencilla de obtener Subversion es descargando un paquete binario construido para su sistema operativo. El sitio web de Subversion (http://subversion.tigris.org) dispone a menudo de estos paquetes disponibles para su descarga, publicados por voluntarios. El sitio web contiene generalmente paquetes que incluyen instaladores gráficos para los usuarios de los sistemas operativos de Microsoft. Si usted usa un sistema operativo Unix o similar, puede usar el sistema nativo de distribución de paquetes de su sistema (RPMs, DEBs, el árbol de ports, etc.) para obtener Subversion.

Alternativamente, usted puede compilar Subversion directamente a partir del código fuente. Del sitio web de Subversion, descargue la última versión del código fuente. Después de desempaquetarlo, siga las instrucciones del fichero INSTALL para compilarlo. Observe que cada paquete de código fuente que se publica contiene todo lo necesario para construir un cliente de línea de comandos capaz de comunicarse con un repositorio remoto (en particular, las bibliotecas apr, apr-util y neon). Sin embargo, las partes opcionales de Subversion tienen otras muchas dependencias, tales como la base de datos Berkeley DB y posiblemente el servidor web Apache. Si usted quiere hacer una compilación completa, asegúrese de tener todos los paquetes documentados en el fichero INSTALL. Si planea trabajar en el propio Subversion, puede usar su programa cliente para obtener la última y más reciente versión del código fuente. Este procedimiento está documentado en “Obtenga el código fuente”.

¿Cómo crear repositorios?

Un repositorio es un área en su sistema donde el sistema de control de versiones va a guardar su programa. Su programa se guarda en una serie de archivos que guardan toda la historia de su programa. Usted puede ingresar toda la historia de las versiones de su programa.

Para crear un repositorio en subversion, usted puede utilizar el comando svnadmin create:

$ svnadmin create /datos/repositorios/direcciones

Esto creará un repositorio llamado direcciones en el directorio datos/repositorio (que primero debe existir). De preferencia (pero no obligatoriamente) usted debe hacer esto en un servidor, para que se pueda conectar a el repositorio desde otras máquinas.

 

¿Cómo crear un cliente web?

Si queremos tener acceso remoto a través de web a los repositorios de subversion para adicionar, actualizar, descargar contenidos de los repositorios, podemos utilizar el módulo WebDAV de acceso, pero si lo que queremos es visualizar el repositorio a través de web y poder verificar cambios, versiones, comparaciones debemos utilizar el cliente web de Subversion WebSVN.

Pasos:

• Abrir una consola
• Instalar el paquete de WebSVN

sudo apt-get install websvn

• Al momento de instalar nos pregunta si queremos configurar el acceso a los repositorios, seleccionamos la opción Yes.
• Al momento de preguntarnos por el servidor, dejamos seleccionadas todas las opciones y Ok
• Suministramos el directorio de los repositorios, antes configurado

/home/svn
y seleccionamos Ok

• Dejamos en blanco la casilla para listar todos los repositorios y Ok
• Los permisos están asignados al usuario del servidor web entonces no tendremos problemas, Ok
• El servicio termina su instalación y se reinicia el servidor web
• Abrir un navegador e ir a la dirección :

http://<ipServidor>/websvn

 

 

Principales comandos

svn

El programa cliente de línea de comandos.

svnversion

Programa para informar del estado (en términos de revisiones de los elementos presentes) de una copia de trabajo.

svnlook

Una herramienta para inspeccionar un repositorio de Subversion.

svnadmin

Herramienta para crear, modificar o reparar un repositorio de Subversion.

svndumpfilter

Un programa para filtrar el formato de salida de volcado de repositorios Subversion.

mod_dav_svn

Un módulo para el servidor HTTP Apache usado para hacer que su repositorio esté disponible a otros a través de una red.

svnserve

Un servidor independiente, ejecutable como proceso demonio o invocable por SSH; otra manera de hacer que su repositorio esté disponible para otros a través de una red.

 

 

Fuente:

http://es.wikipedia.org/wiki/Subversion

http://svnbook.red-bean.com/nightly/es/index.html

 

Calidad del Software

Concepto de calidad.

Se define la calidad de software como la ausencia de errores de funcionamiento, la adecuación a las necesidades del usuario, y el alcance de un desempeño apropiado (tiempo, volumen, espacio), además del cumplimiento de los estándares. Los objetivos que la calidad persigue son: La aceptación (utilización real por parte del usuario) y la Mantenibilidad (posibilidad y facilidad de corrección, ajuste y modificación durante largo tiempo). Para alcanzar estos objetivos, es necesaria una actitud y compromiso de todo el personal que se encuentre en el desarrollo del proyecto, y en todas y cada una de las etapas (en general, planeación, análisis, diseño, programación, pruebas, mantenimiento) correspondientes al ciclo de vida que se hubiese seleccionado para el proyecto.

 

La tendencia de la calidad.

El primero llamado Kuizen se refiere a un sistema de mejora continua del proceso, su objetivo es desarrollar un proceso mensurable

El segundo se llama Aturimae Hinshitsu examina los problemas invisibles por los que pueda o está atravesando el proceso, este segundo paso se encarga de trabajar para optimizar su impacto en el proceso.

El siguiente paso llamado kansei se centra principalmente en el usuario del producto, conduce a la mejora del producto y potencialmente al proceso que lo creo.

El último paso llamado miryokuteki  hinshitsu orientado específicamente a la gestión, se encarga de ver cómo funciona el producto en el mercado.

 

Garantía de calidad del software.

La garantía de calidad del software comprende una gran variedad de tareas asociadas a siete actividades principales. La calidad del software debe estar diseñada para el producto o sistema no es algo impuesto a posteriori. Por esta razón la garantía de calidad del software comienza realmente con un conjunto de herramientas y métodos técnicos que ayudan al analista a conseguir una especificación y un diseño de alta calidad.

Tareas que se deben llevar a cabo en un plan de Garantía de calidad del Software:

1- Revisión del diseño del sistema
2- Revisión de requerimientos de software
3- Revisión del diseño preliminar
4- Revisión del diseño detallado (a nivel módulos)
5- Revisión del plan de prueba de integración
6- Revisión del código
7- Revisión de los procedimientos
8- Auditorías de los estándares de documentación
9- Auditorías del control de configuración
10- Auditorías de prueba
11- Recolección, evaluación y análisis de los datos de defectos
12- Certificación de herramientas
13- Mantenimiento de registros

 

Revisiones del software.

Es un proceso o una reunión durante los cuales un producto de software es examinado de cerca por el personal del proyecto, encargados, usuarios, clientes, representantes del usuario, u otros partidos interesados para el comentario o la aprobación.

Variedades de revisión del software

Las revisiones del software se pueden dividir en tres categorías:

• Revisiones de par del software.

Son conducidos por el autor del producto del trabajo, o por unos o más colegas del autor, para evaluar el contenido técnico y/o la calidad del trabajo.

• Revisiones de la gerencia del software.

Son conducidos por los representantes de la gerencia para evaluar el estado del trabajo hecho y para tomar decisiones con respecto a actividades enes sentido descendiente.

• Revisiones de la intervención del software.

Son conducidos por el personal externo al proyecto del software, para evaluar conformidad con especificaciones, estándares, acuerdos contractuales, u otros criterios.

Diversos tipos de revisiones

• Revisión de código.

Es la examinación sistemática (a menudo como revisión de par) del código de fuente de la computadora.

• Programación del par.

Es un tipo de revisión de código donde dos personas desarrollan código juntas en el mismo sitio de trabajo.

• Inspección.

Es un tipo muy formal de revisión de par donde los revisores están siguiendo un proceso bien definido para encontrar defectos.

• Walkthrough.

Es una forma de revisión de par donde el autor conduce a miembros del equipo del desarrollo y otros partidos interesados a través de un producto de software y los participantes pida a preguntas y hace comentarios sobre defectos.

• Revisión técnica.

Es una forma de revisión de par en la cual un equipo del personal cualificado examina la conveniencia del producto de software para su uso previsto e identifica discrepancias de especificaciones y de estándares.

El valor más obvio de las revisiones del software (especialmente revisiones formales) es que pueden identificar ediciones anterior y más barato que ellos sería identificado probando o por el uso del campo ( proceso de la detección del defecto). El coste para encontrar y para fijar un defecto por una revisión bien-conducida puede ser uno o dos órdenes de la magnitud menos que cuando el mismo defecto es encontrado por la ejecución de la prueba o en el campo.

Un segundo, pero en última instancia más importante, el valor de las revisiones del software es que pueden ser utilizados para entrenar a autores técnicos en el desarrollo extremadamente de los documentos del bajo-defecto, y también identificar y quitar las insuficiencias de proceso que animan los defectos ( proceso de la prevención del defecto).

 

Revisiones técnicas formales.

Tienen como objetivo fundamental descubrir errores en la función, lógica o implementación de cualquier representación del software. Verificar el cumplimiento de los requisitos Garantizar el cumplimiento de los estándares. Conseguir un desarrollo uniforme del software Obtener proyectos que hagan más sencillo los trabajos técnicos (análisis que permitan buenos diseños, diseños que permitan implementaciones sencillas, estrategias de pruebas que faciliten éstas,…).

Se eliminan errores en forma relativamente temprana (barato y fácil de corregir).

Cada revisión se conduce en forma de una reunión cuidadosamente planeada y controlada

–          La reunión de revisión

Entre 3 y 5 personas (grupo pequeño) Preparación previa (2 horas por persona) Especificación precisa (formal o informal)

–          Estándares de codificación

Duración máxima 2 horas (lento pero cansado) Foco en un segmento específico Participan los revisores y el productor

–          Directrices para la revisión

Revisar el producto y no al productor Indicar los errores con tino, tono constructivo Mantenerse estrictamente dentro de la agenda No irse por las ramas Limitar el debate Algunos asuntos pueden dejarse para discusión posterior Enunciar problemas no resolverlos Problema debería ser resuelto por el productor Tomar notas (pizarra deseable)

RTFs: son un filtro que permite “purificar” las actividades de ingeniería de software. se aplican en diversos momentos del desarrollo para detectar defectos Aprovecha la diversidad de un grupo de personas para: señalar la necesidad de mejoras en el producto de ingeniería. Confirmar las partes en las que no es necesaria una mejora. Conseguir un trabajo técnico de calidad más uniforme.

 

Fiabilidad del software.

La fiabilidad del software se define como la probabilidad de operación libre de fallos de un programa de computadora es un entorno determinado y durante un tiempo específico.

La fiabilidad del software, a diferencia de otros factores de calidad, puede ser medida o estimada mediante datos históricos o de desarrollo. La fiabilidad del software se define en términos estadísticos como la probabilidad de operación libre de fallos de un programa de computadora es un entorno determinado y durante un tiempo específico Siempre que se habla de fiabilidad, surge una pregunta fundamental ¿ qué se entiende por el término fallo ? En el contexto de cualquier disquisición sobre calidad y fiabilidad del software, el fallo es cualquier falla de concordancia con los requisitos del software. Incluso en esta definición existen grados. Los fallos pueden ser simplemente desconcertantes o ser catastróficos. Puede que un fallo sea corregido en segundos mientras que otro lleve semanas o incluso meses.

Para modelizar la fiabilidad del software, se deben considerar primero los principales factores que le afecten : Introducción de fallos, eliminación de fallos y entorno.

Los modelos de fiabilidad del software entran en dos grandes categorías :

1. Modelos que predicen la fiabilidad como una función cronológica del tiempo (calendario).
2. Modelos que predicen la fiabilidad como una función del tiempo de procesamiento transcurrido (tiempo de ejecución de CPU).

Como parte de la seguridad del software, se puede dirigir un proceso de análisis y modelización. Inicialmente, se identifican los riesgos y se clasifican por su importancia y su grado de riesgo. Cuando se han identificado estos riesgos del sistema, se utilizan técnicas de análisis para asignar su gravedad y su probabilidad de ocurrencia. Para que se efectivo, se tiene que analizar el software en el contexto del sistema completo. El análisis del árbol de fallos construye un modelo gráfico de las combinaciones secuenciales y concurrentes de los sucesos que pueden conducir a un suceso o estado del sistema peligroso.

 

Prueba de errores para el Software.

En los años 60, un ingeniero industrial japonés desarrollo una técnica de garantía de la calidad, en la que su objetivo era la prevención y/o corrección de errores en el proceso de fabricación. Fue denominado poku yoke, estos son dispositivos que conducen a la prevención de un problema potencial antes de que ocurra y a la rápida detección de problemas de calidad si  ya se han producido.

Un dispositivo Poku Yoke presenta un conjunto de características comunes,

• Es simple y barato
• Es parte del proceso
• Esta localizado cerca de la tarea del proceso donde están ocurriendo los errores.

En fin esta técnica (Poka yoke) puede ser implementado en el uso de la Ingeniería del Software, a través de pequeños Scripts en el cual se ejecuta sobre las aplicaciones para detectar fallos, esta técnica puede aplicarse a los niveles de diseño, codificación y pruebas y proporciona un filtro efectivo de garantía de la calidad

 

El estándar de calidad 9001

Designa un conjunto de normas sobre calidad y gestión que una organización debe cumplir para alcanzar la completa satisfacción del cliente a través de productos y servicios que cumplan las perspectivas del cliente. Establecidas por la Organización Internacional de Normalización. Aplicable a cualquier organización que diseñe, desarrolle, manufacture, instale o dé servicio a un producto o que proporcione cualquier forma de servicio. Es la única implementación para la que auditores externos pueden entregar certificaciones.

Para la industria del software los estándares relevantes son.

• ISO 9001 desarrollo de un producto que implique diseño
• ISO 9000-3 es un documento específico que interpreta el ISO 9001 para el desarrollo de software
• ISO 9004-2 proporciona directrices para el servicio de facilidades del software como soporte de usuario

Secciones del ISO 9001

ISO 9001 está compuesto por cinco secciones que especifican las actividades que necesitan ser consideradas al implementar el sistema:

1. Realización del Producto
2. Sistema de Gestión de la Calidad
3. Responsabilidad de Gestión
4. Gestión de Recursos
5. Medición, Análisis y Mejora

De la primera pueden ignorarse las partes no aplicables a la organización. Las otras cuatro secciones aplican a todas las organizaciones.

 

Fuente: Roger Pressman Ingenieria del Software un enfoque practico V Ed.pdf[Quinta edición]:México

Para ver el libro completo click aqui…

Para descargar el libro click aqui… ó  aqui…

Análisis y Gestión de Riesgos

Haga click para ver el documento: Gestión de Riesgos

Fuente: Roger Pressman Ingenieria del Software un enfoque practico V Ed.pdf[Quinta edición]:México

Para ver el libro completo click aqui…

Para descargar el libro click aqui… ó  aqui…