Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
publicado a la(s) 9 may. 2017 22:55 por Carlos Enrique [ actualizado el 10 may. 2017
14:52 ]
Introducción
En general, una vez validado que el sistema responde a los principales requisitos
funcionales especificados, el usuario realizará las pruebas de aceptación, corrigiéndose los
errores encontrados y traspasándose al fin al entorno de producción. Sin embargo, en muy
pocas ocasiones se validan de manera rigurosa los requisitos funcionales y los no
funcionales, o se ejecutan validaciones que aseguren que el sistema es lo suficientemente
robusto y estable como para pasar a un entorno productivo con las garantías adecuadas.
Tampoco se realizan por ejemplo estimaciones de los recursos necesarios para el sistema,
imprescindibles para un adecuado dimensionamiento de los servidores, o se anticipan
eventuales picos de trabajo, o, en resumen, todo aquello que al fin asegure la satisfacción
total del usuario.
Hay que considerar entonces que estas eventualidades además de provocar un coste
económico importante, principalmente por el elevado número de personas involucradas en
su resolución, también producen la pérdida de confianza de los usuarios en el sistema.
Los estándares definen un conjunto de criterios que guían la forma en que se aplican
procedimientos y metodologías al software desarrollado, la certificación de calidad permite
una valoración independiente de la organización, donde se demuestra la capacidad de
desarrollar productos y servicios de calidad.
Prácticamente, y para exponerlo del modo más sencillo, el modelo está compuesto por un
conjunto de preguntas y criterios ordenados por áreas de gestión. Estas preguntas y criterios
están diseñados de tal forma tal que en el ejercicio de discusión que se produce al intentar
responderlas, se genera una evaluación crítica de todos los aspectos relevantes de la gestión
actual de la organización.
Al mismo tiempo, quedan identificadas cuáles son las prácticas que se necesitan mejorar, y
aquellas prácticas que constituyen fortalezas de la organización, en todas las áreas de
gestión.
Los conceptos y valores sobre los cuales está construido el modelo son los habitualmente
conocidos como de Calidad Total. Sin embargo, ningún modelo prefiere un estilo
particular, ni recomienda implantar determinadas prácticas, ni tampoco sugiere el uso de
ciertas metodologías o sistemas de gestión en desmedro de otras. Tampoco aconseja qué
plan de acción seguir, o cómo desarrollar un plan de calidad. La propia evaluación crítica
de la gestión de la organización funciona como marco para que sus directivos descubran
cuales son los pasos a dar, y donde reformar su organización.
publicado a la(s) 10 may. 2017 13:25 por Carlos Enrique [ actualizado el 10 may. 2017
19:07 ]
El éxito en la medición del software está ligado a la obtención, definición y manipulación
conjunta de dos modelos:
Modelos empíricos
Modelos numéricos
publicado a la(s) 10 may. 2017 13:48 por Carlos Enrique [ actualizado el 10 may. 2017
21:00 ]
Actualmente existe un gran interés por la calidad de los productos o servicios. En el
mercado actual que es tan competitivo no basta con producir y distribuir los productos o
servicios, vender es lo importante y esto se genera con la aceptación por parte del cliente, se
dice que la calidad no tiene un concepto solo se reconoce. Sin embargo la calidad en el
software es un concepto complejo que no es directamente comparable con la calidad de un
producto. El software se ha convertido en la actualidad en uno de los principales objetivos
estratégicos de las organizaciones debido a que, cada día, los procesos mas importantes de
las organizaciones y su supervivencia dependen del funcionamiento del software.
Según Pressman (2005), es la concordancia del software producido con los requerimientos
explícitamente establecidos y con los estándares de desarrollo prefijados y con los
requerimientos implícitos no establecidos formalmente, que desea el usuario. Otra
definición que contempla Vega, Rivera & García (2008) en su libro. Y que es propuesta por
la organización internacional de estándares (ISO/IEC DEC 9126): “La totalidad de
características de un producto de software que tienen como habilidad, satisfacer
necesidades explícitas o implícitas”.
Satisfacción del usuario = producto manejable + buena calidad + entrega dentro del
presupuesto y tiempo.
Glass (1998), afirma que la calidad es importante, pero si el usuario no está satisfecho, nada
más importa en realidad. De igual forma afirma que la calidad de un producto es una
función de cuánto cambia el mundo para mejorar. Esta visión de la calidad afirma que si un
software proporciona beneficio sustancial a sus usuarios finales, éstos están dispuestos a
tolerar problemas ocasionales en aspectos como la confiabilidad y el desempeño.
Control de calidad
Garantía de la calidad
El costo de la calidad incluye todos los costos que se generan o que demandan el desarrollo
de las actividades relacionadas con la calidad. Los estudios de costo de la calidad se llevan
a cabo para ofrecer una línea base e identificar oportunidades que reduzcan el costo de
calidad y proporcionan una base que sirva de comparación. La base de normalización casi
siempre es monetaria, ya que se tienen los datos necesarios para evaluar dónde se
encuentran las oportunidades para mejorar los procesos, se puede evaluar el efecto de los
cambios en términos monetarios. Los costos de calidad se dividen en:
2) Evaluación y fallas; estos costos incluyen actividades que permiten comprender mejor la
condición del producto a través de cada proceso. Algunos ejemplos de costos de valuación
incluye ni inspección en el proceso y procesos, calibración y mantenimiento de equipo
además de las pruebas correspondientes. Los costos de fallas son aquellos que
desaparecerán si no hubiese defectos antes de enviar el producto a los clientes. Estos costos
se subdividen en costos de fallas internas y externas.
Se incurren los costos de fallas internas cuando se detecta un defecto en el producto antes
del envío, dichos costos incluyen reelaboración, reparación y análisis el modo de falla. Los
costos de fallas externas se asocian con defectos detectados después de que el producto ha
sido enviado al cliente algunos ejemplos de estos son la resolución de las quejas,
devolución y reemplazo del producto, soporte de ayuda en línea y trabajo de garantía.
" el trabajo técnico necesita revisarse por la misma razón que los lápices necesitan gomas,
errar es de humanos. La segunda razón por la que se necesitan las revisiones técnicas es que
aunque la gente sea buena al captar algunos de sus propios errores, las grandes clases de
errores escapan de su creador con más facilidad de lo que se le escapan a alguien más".
El objetivo principal de las revisiones técnicas formales es descubrir los errores durante el
proceso, de modo que no se conviertan en defectos después de liberar el software. El
beneficio de las revisiones técnicas formales es el descubrimiento temprano de los errores
de modo que ya no se propaguen a la etapa siguiente en el proceso de desarrollo de
software.
De acuerdo a los estudios realizados por Vega et al (2008), algunas normativas de calidad
en los sistemas de información y que ayudan a la realización, además de aplicar mejores
prácticas en las organizaciones son:
Los sistemas ISO de garantía de calidad fueron creados para ayudar a las organizaciones a
garantizar que sus productos y servicios satisfacen las expectativas de los clientes al
cumplir las especificaciones. El estándar ISO 9000 describe un sistema que garantiza la
calidad en términos genéricos y que se puede aplicar a cualquier negocio sin importar los
productos o servicios ofrecidos. ISO 9000 requiere que los sistemas de operaciones de
calidad y una compañía se sometan a revisión de auditores de una tercera entidad, el cual
tiene conocimiento del estándar y de su funcionamiento. Antes del registro exitoso, los
auditores extienden a la compañía un certificado de la organización que representan.
Entrevistas de auditoría semianuales garantizan la concordancia continua con el estándar.
Entre las políticas y procedimientos que se deben de demostrar en una auditoría están las
siguientes:
Describir el proceso.
Producir un manual operativo.
Desarrollar métodos para controlar los documentos.
Establecer métodos para la conservación de registros.
Para planeación.
Para requisitos del cliente.
Para actividades técnicas, por ejemplo análisis diseño y pruebas.
Para supervisión y gestión del proyecto.
publicado a la(s) 10 may. 2017 13:43 por Carlos Enrique [ actualizado el 10 may. 2017
19:12 ]
Según Juran (1992), la calidad, para poder ser entendida de una mejor manera y
posteriormente ser medida con eficacia, debe ser expresada por medio de otros términos
que tengan más sentido para el usuario. En el caso del software. Estos factores son el medio
por el cual se traduce el término “calidad” al lenguaje de las personas que manejan la
tecnología.
Los factores de calidad que afectan a la calidad del software se dividen en dos grandes
grupos:
En cada caso debe presentarse una medición. Se debe comparar el software con algún
conjunto de datos y obtener así algún indicio sobre la calidad. McCall, Richards & Walters
(1977), propusieron una clasificación de los factores que afectan directamente a la calidad
del software. Estos factores se muestran en la figura 2.30 En ella se concentran tres
aspectos importantes de un software:
Características operativas.
Capacidad para experimentar cambios.
Capacidad para adaptarse a nuevos entornos.
A continuación se describen los factores que propone McCall, Richards & Walters.
Corrección
El grado en que el programa cumple con su especificación y satisfacer los objetivos que
propuso el cliente.
Confiabilidad
Eficiencia
Integridad
El grado de control sobre el acceso al software o los datos por parte de las personas no
autorizadas.
Facilidad de uso
El esfuerzo necesario para aprender, operar y preparar los datos de entrada de un programa
interpretan la salida.
Facilidad de mantenimiento
Flexibilidad
El esfuerzo que demanda probar un programa con el fin de asegurar que realiza su función.
Portabilidad
Facilidad de reutilización.
Interoperabilidad
Corrección
Confiabilidad
El grado en que se puede esperar que un producto de software lleve a cabo sus funciones
esperadas con la precisión requerida.
Eficiencia
Integridad
El grado en que puede controlarse (facilitar y restringir) el uso y acceso al software y a los
datos, tanto al personal autorizado como al no autorizado.
Facilidad de uso
Facilidad de mantenimiento
Flexibilidad
El esfuerzo requerido para modificar un producto de software una vez que se encuentra ya
liberado o en producción, esto es, una vez que el usuario esté haciendo uso de él.
Facilidad de prueba
El esfuerzo requerido para probar un producto de software, de tal forma que se asegure que
realiza las funciones especificadas por el usuario.
Portabilidad
Reusabilidad
El grado en que un producto de software (o alguna de sus partes) pueda volver a ser
utilizado en otras aplicaciones, aún cuando la funcionalidad de la misma cambie.
Facilidad de interoperación
El esfuerzo requerido para lograr que un producto de software trabaje con otro,
compartiendo recursos.
publicado a la(s) 10 may. 2017 13:37 por Carlos Enrique [ actualizado el 10 may. 2017
19:17 ]
La medición asigna números o símbolos a atributos de entidades reales. Esto requiere un
modelo de medición que abarque un conjunto existente de reglas. En el contexto de la
ingeniería del software una medida proporciona una indicación cuantitativa de la extensión,
la cantidad, la dimensión, la capacidad o el tamaño de algún atributo de un producto o
proceso. La medición ocurre como resultado de la recopilación de uno o más puntos de
datos. Una métrica de software relaciona de alguna manera las medidas individuales, de
igual manera un ingeniero de software recopila medidas y desarrolla métricas para obtener
los indicadores.
Antes de generar e introducir una serie de métricas del producto debemos contemplar que
se:
Las métricas del software sólo serán útiles si están caracterizadas de manera efectiva y se
validan para probar su valor. Según Lethbridge (2003), los siguientes principios son
representativos de muchos otros que podrían proponerse para caracterizar y validar las
métricas. Una métrica debe tener propiedades matemáticas deseables. Es decir, el valor de
la métrica debe estar en un rango significativo por ejemplo, de cero a uno, donde cero
realmente significa ausencia, uno indica el valor máximo y 0.5 representa el punto medio.
Además, una métrica pretende estar en una escala racional no debe contar con componentes
que sólo se miden en una escala ordinal. Cuando una métrica representa una característica
de software que aumenta cuando se presentan rasgos positivos o que disminuya al encontrar
rasgos indeseables, el valor de la métrica debe aumentar o disminuir en el mismo sentido.
Cada métrica debe validarse empíricamente en una amplia variedad de contextos antes de
publicarse o aplicarse la toma de decisiones. Una métrica debe medir el factor de interés,
independientemente de otros factores. Debe crecer para aplicarse a sistemas grandes y
funcionar en diversos lenguajes de programación y dominios de sistemas. Aunque la
formulación, caracterización y validación son críticas, la recopilación y el análisis son las
actividades que dirigen el proceso de medición. Roche(1994) sugiere las siguientes
directrices para estas actividades:
Aunque casi todas las métricas de software satisfacen esos atributos, algunas métricas de
uso común no cumplen con una o dos de ellas. Aunque se ha propuesto una amplia
variedad de taxonomía en métricas, el siguiente esquema atiende a las cuatro más
importantes en el desarrollo del software.
Métricas para el modelo de análisis. Estas métricas atienden varios aspectos de la etapa
de análisis en donde se incluyen:
Métricas para el modelo de diseño. Estas métricas cuantifican los atributos del diseño de
manera tal que le permiten al ingeniero de software evaluar la calidad del diseño, la métrica
incluye:
Métricas para el código fuente. Estas métricas miden el código fuente y se usan para
evaluar su complejidad, además de la facilidad con que se mantiene y prueba entre otras
características como:
ISO
publicado a la(s) 10 may. 2017 13:55 por Carlos Enrique [ actualizado el 23 may. 2017
16:46 ]
La Organización Internacional para la Estandarización, mejor conocida como ISO, es la
agencia especializada en estandarización, conformada por representantes de los cuerpos
normalizadores, fue establecida oficialmente el 23 de febrero de 1947 con el objeto de
promover la estandarización internacional, de tal manera que se facilitara el intercambio
internacional de bienes y servicios casi como el desarrollo científico y tecnológico.
Actualmente abarca los estándares nacionales de 91 países. En los Estados Unidos, la
representación se llama The American National Standards Institute (ANSI).
Formas y técnicas de documentar algoritmos y programas
publicado a la(s) 10 may. 2017 2:39 por Carlos Enrique [ actualizado el 23 may. 2017
18:00 ]
La documentación
Manual de mantenimiento
Documentación interna
Esta documentación cubre los aspectos del programa relativos a la sintaxis de lenguaje.
Esta documentación está contenida en los comentarios entre llaves, paréntesis o asteriscos.
Algunos temas a considerar son:
Documentación externa
Documentación ajena al programa fuente, que se suele incluir en un manual que acompaña
al programa. Esta documentación debe incluir:
Reglas de documentación
Un programa bien documentado es aquel que otras personas pueden leer, usar y modificar.
Existe muchos tipos de documentación y con frecuencia los temas a incluir dependen del
programa. A continuación, señalamos algunas características esenciales de documentación
de un programa.