Professional Documents
Culture Documents
TESIS
P R E S E N T A:
RESUMEN .......................................................................................................... I
INTRODUCCIÓN .............................................................................................. VI
CAPÍTULO I
FUNDAMENTOS DE CALIDAD DEL SOFTWARE
CAPÍTULO III
CONSIDERACIONES PRÁCTICAS
CAPITULO 1
FUNDAMENTOS DE CALIDAD DE SOFTWARE
Esto es conseguir hoy por hoy productos portables, fáciles de mantener y/o
ampliar, sencillos de entender, de validación accesible, compatibles con otros
sistemas rápidos y efectivos, más un sinfín de características que provoque el
terminar o trascender la llamada crisis del software.
Algunas de las características que debe cumplir un software son corrección,
fiabilidad, eficiencia, facilidad de uso, facilidad de mantenimiento entre otras,
mientras más características reúna un desarrollo de software mayor será su
calidad.
Existen varios modelos de calidad muy útiles que pueden ser usados para
evaluar y medir la calidad de un software algunos de ellos son el modelo
SPICE, el modelo CMM, el modelo PROSOFT y MOPROSOFT entre otros.
La calidad del software tiene dos enfoques diferentes por un lado tenemos a la
calidad del proceso que es cuando se diseña, desarrolla y construye el
software así como cuando se mantiene y por otro lado se tiene la calidad del
producto que es la mejora que se le hace a todo el proceso y al producto en
I
general para esto es necesario comprender desde el principio del proyecto las
necesidades reales y completas de los usuarios con tanto detalle como sea
posible (requerimientos) mientras mas claras y detalladas sean mas fáciles de
solucionar e implementar van a ser.
II
CAPITULO 2
PROCESOS DE ADMINISTRACIÓN DE CALIDAD DE SOFTWARE
Algunos de los factores que afectan la calidad del software son corrección,
fiabilidad, eficiencia, integridad, facilidad de uso, flexibilidad, facilidad de prueba
entre otras.
III
CAPITULO 3
CONSIDERACIONES PRÁCTICAS
Los requerimientos del software son una descripción abstracta de los servicios
que el sistema debería proporcionar al cliente, y las limitaciones bajo las cuales
éste debería operar.
Todo requerimiento debe cumplir con diversos factores como son la seriedad al
realizar el producto, los niveles de integridad del software para evitar posibles
fracasos y la caracterización de los defectos que sirve para futuras revisiones.
Existen varias técnicas de dirección de calidad del software, por ejemplo, las
técnicas estáticas que son aplicadas a la documentación del proyecto, las
técnicas personales intensivas se basan en revisiones y auditorias y requieren
de mas de una persona, técnicas analíticas como análisis de la complejidad,
control del análisis del flujo, y el análisis algorítmico, las técnicas dinámicas que
Incluyen técnicas de prueba, pero también la simulación, el chequeo de
modelos y la ejecución simbólica pueden ser consideradas dinámicas.
IV
También tenemos las pruebas que son los procesos del aseguramiento
descritos en la SQA y V&V examinan cada salida concerniente a la
especificación del requerimiento del software para asegurar la consistencia, lo
completo, la corrección, y el buen funcionamiento del software.
Existen varios tipos de pruebas como son prueba genérica, prueba dinámica,
marco del testeo etc.y que aplicadas correctamente resultan bastante efectivas
para enviar un software de calidad.
Por último tenemos la Medición y las métricas que ya sean para el proceso de
desarrollo del software como para la documentación, como para programación
tradicional y orientada a objetos y ahora también dentro de la creación de
software para la reutilización son y serán instrumentos que nos ayuden a tener
una visión más amplia de cómo van y como salieron las cosas al final del
trabajo.
V
INTRODUCCIÓN
Actualmente la palabra "calidad" se usa cada vez con más frecuencia en las
empresas, ya sea en los sectores de alimentos, industria o servicios y
especialmente en el sector de Tecnología Informática (TI).
Dicha atención se debe en gran parte al interés de la industria sobre la calidad
y a la necesidad de controlar gastos de mantenimiento crecientes.
VI
Por supuesto existen modelos, métricas y herramientas que complementan
estos procesos y nos ayudan en la mejora de la calidad.
Para cubrir dichos objetivos primero debemos entender bien a que se le llama
calidad del software hay quien piensa que la calidad es un simple papeleo
pesado, o muchas reuniones para establecer un proceso, conseguir un sello
de calidad en nuestro producto y así mejorar su publicidad punto que resultaría
muy poco efectivo para la calidad del software, o piensan que simplemente es
tener un producto mejor que el de la competencia sin importar costos ni
garantías. La calidad va mucho mas allá de todo eso y por lo mismo es un tema
que debe preocuparnos ya que los clientes quieren un producto de calidad y
por lo tanto evalúan las soluciones que se les proporcionan, muchas veces con
ayuda de auditores o gente conocedora del campo, los proyectos y definición
de los requerimientos siempre varia de uno a otro, exigen fiabilidad y seguridad
y muy a menudo preguntan o quieren conocer el proceso con el que se
desarrollo su proyecto.
Por todo lo anterior el siguiente proyecto nos presenta los métodos y modelos
que nos pueden ayudar a mejorar la calidad de nuestro producto, así como las
técnicas de dirección de la administración del software, las métricas y/o
medidas de dicho producto todo con el mismo objetivo: presentar un proyecto
que satisfaga las exigencias y necesidades del cliente, que sea seguro y
confiable, que su mantenimiento y su adaptación a otros sistemas y cambios
dentro del mismo sean los propios y sobre todo que los costos no representen
mas que una ganancia una perdida para el cliente
VII
CAPÍTULO I
Otro aspecto importante que nos frena en cuanto a lograr calidad es que dicha
industria exige y crece mas rápido que las mismas metodologías y capacidad
de las personas, porque aunque todo se facilita poco a poco por ejemplo el uso
de herramientas CASE (Software de Ingeniería asistida por Computadora), la
ingeniería de software requiere todavía de mucho capital humano e intelectual,
no de insumos ni de materias primas.
Tales circunstancias han provocado una llamada crisis del software, que
principalmente se manifiesta en la demora en entregas del producto, los
excesos de presupuestos, la falta de cumplimiento de los requerimientos
iniciales, entre otros.
1
La pregunta es ¿Existen criterios para evaluar la calidad del software?
Anteriormente la calidad de un programa o sistema se evaluaba de acuerdo al
número de defectos por cada mil líneas de código. En 1988, un estudio
realizado en los EEUU, demostró que se introducían cerca de sesenta defectos
por cada mil líneas de código (60 def/KLOC), durante las etapas de análisis,
desarrollo y puesta en operación ya en la producción la cantidad aumenta.
Actualmente para alcanzar un completo y preciso concepto de la calidad del
software se requiere una clara y eficaz congruencia entre los requerimientos y
características del producto, para poder alcanzar una plena satisfacción del
usuario.
Esto es conseguir hoy por hoy productos portables, fáciles de mantener y/o
ampliar, sencillos de entender, de validación accesible, compatibles con otros
sistemas rápidos y efectivos, más un sinfín de características que provoque el
terminar o trascender la llamada crisis del software.
Claro esta que este debe ser un proyecto planeado a largo plazo ya que
conlleva el cambio y adaptación a muchas nuevas reglas, políticas y
procedimientos, pero sobre todo el paso a un amplio concepto de lo que es
cultura de la calidad total.
2
Dentro de un programa de gestión y aseguramiento de la calidad se deben
tomar en cuenta varios aspectos, primero el modelo a seguir y la definición de
lo que es calidad para la propia empresa o institución, identificar componentes
tipo de resultado y tipo de contribuyente, fijar metas, objetivos y tiempos,
técnicas de medición y de comparación, entre muchas otras cosas que mas
adelante se podrán percibir mas claramente.
• Desorganización.
• Falta de planificación.
• Alta dependencia de los “héroes”.
• Dedicamos nuestros esfuerzos de hoy a arreglar lo que se hizo mal ayer.
• El producto (software) es algo intangible y no constreñido por las leyes
físicas.
• La disciplina, ingeniería del software, es relativamente reciente y muchos
de sus conceptos importantes están aún inmaduros.
• Carencia de un corpus de conocimiento aceptado mayoritariamente que
sirva como fundamentos.
• Escasa presión del mercado.
Todos estos factores dan como resultado una empresa inmadura carente de la
capacidad para alcanzar una calidad total y por lo tanto la mantiene alejada de
lograr productos de software con calidad y mucho menos le permite gestionar
sus procesos de calidad ni evaluar efectivamente sus productos frente a otros
en el mercado.
3
• Procesos software normalmente improvisados.
• Si se han especificado, no se siguen rigurosamente.
• Organización reactiva (resolver crisis inmediatas).
• Planes y presupuestos excedidos sistemáticamente, al no estar basados
en estimaciones realistas.
• Si hay plazos rígidos, se sacrifican funcionalidad y calidad del producto
para satisfacer el plan.
• No existen bases objetivas para juzgar la calidad del producto.
• Cuando los proyectos están fuera de plan, las revisiones o pruebas se
recortan o eliminan.
• El 90% de los proyectos no alcanzan los objetivos.
• El 40% fracasan por completo.
• El 29% no se entregan nunca.
• Gastos de adaptación tecnológica al año 2000.
• Coste de demandas y litigios legales añadidos.1
Algunas características de calidad con las que debe contar cualquier producto
de software para poder cumplir los requerimientos de usuario así como tiempos
de entrega y confiabilidad son:
1
www.calidaddelsoftware.com.
4
Interoperabilidad.- Podré hacerlo interactuar con otro sistema.
Características operativas.
Capacidad de soportar los cambios.
Adaptabilidad a nuevos entornos.2
2
www.ingenierosoftware.com/calidad
5
Los modelos más actuales generalmente están enfocados a la mejora de
procesos, ya que la idea de calidad total se refiere a la calidad desde el inicio
del proyecto y el hecho de tener mejores procesos nos conlleva a un mejor
resultado.
• Modelo PROSOFT.
• Modelo MOPROSOFT.
• NORMA ISO 9000-2000 .
• NORMA ISO/IEC TR 15504.
• Modelo CMM(Modelo de Capacidad y Madurez).
• Modelo SPICE (Mejora de Procesos de Software y capacidad de
determinación).
3
www.economia.gob.mx/
6
México cuenta con un gran potencial para desarrollar la industria del software
por eso la Secretaría de Economía, en coordinación con organismos
empresariales y empresas del sector tecnológico, diseñaron el Programa para
el Desarrollo de la Industria del Software (PROSOFT).
METAS:
7
• Convertir a México en el líder latinoamericano de desarrollo de software
y contenidos digitales en español.
ESTRATEGIAS:
3.- Contar con un marco legal promotor de la industria.- Un marco legal que
fomente el uso de tecnologías de información y el desarrollo de la industria con
reglas como la norma de conservación de mensajes de datos, factura
electrónica y firma digital.
4.- Desarrollar el mercado interno.- Apoyando a las empresas para que usen
hardware y software en sus operaciones (Inventarios, Normas, Contabilidad) y
en su relación con proveedores y clientes (Digitalización de Cadenas de Valor).
8
6.- Alcanzar niveles internacionales en capacidad de procesos.- A efecto de
que las empresas cuenten con las mejores prácticas internacionales en la
producción de sus sistemas. Para ello, se impulsará la normalización, la
creación de una entidad local de certificación, se apoyará la investigación y
desarrollo con el fondo sectorial de apoyo creado por la SE (Secretaria de
Economía) y CONACYT (Consejo Nacional de Ciencia y Tecnología) y se
reconocerá a las mejores empresas a través del Premio Nacional de
Tecnología.
Hoy en día la complejidad con que se realizan los sistemas de información y las
exigencias de los mismos va cada vez mas en aumento, y por lo mismo
muchas veces resulta difícil cumplir con las expectativas de los clientes.
También es cierto que cada día surgen mas herramientas, técnicas y modelos
que nos facilitan esta tarea, ayudando a las empresas encargadas de las
tecnologías de información a generar productos de mayor calidad y que
cumplan con los requerimientos de los clientes, así mismo ayudan también a
mejorar costos y tiempos.
9
Anteriormente aunque se reconocía la necesidad de crear software de calidad
realmente no se había hecho un verdadero esfuerzo por alcanzarla,
afortunadamente surgió PROSOFT que como ya mencione es un programa
realmente enfocado a invertir y no escatimar en recursos tanto humano,
intelectual, económico con el fin de colocar a la industria del software como la
base de la economía mexicana, generando mas empleos y posicionando a
México como líder en construcción de software. 4
1.1.1.2 MOPROSOFT
Tiene mayores ventajas que los modelos que se mencionaran a lo largo del
capítulo porque fue creado tomando lo mejor de todos esos modelos, sus
mejores practicas integrándolas y mejorándolas.
• Fácil de entender.
• Fácil de aplicar.
• No es costoso en su adopción.
• Sirve de base para alcanzar evaluaciones exitosas con otros modelos o
normas.
4
www.software.net.mx/desarrolladores/prosoft.
10
Su principal fortaleza es que integra varias de las prácticas propuestas por los
otros modelos y corrige algunas de sus desventajas, como son el hecho de que
no ha sido liberado por completo o al menos falta el modelo de evaluación;
además, está en proceso de convertirse en norma compitiendo con el proyecto
de norma ISO/IEC TR 15504 y aunque no ha sido aprobado, se planea realizar
pilotos en algunas organizaciones para evaluar qué tan fácil resulta su
implantación determinando los recursos necesarios.
5
alarcos.inf-cr.uclm.es/doc/calidadSI/Index.htm
11
Como ventajas de esta norma podemos mencionar que es específico para el
desarrollo y mantenimiento de software es fácil de entender (24 procesos, 16
páginas) también esta definido como un conjunto de procesos y esta orientado
a mejorar los procesos para contribuir a los objetivos del negocio.
Todo esto con el fin de atraer, desarrollar, motivar, organizar y retener el talento
necesario para sostener el proceso de desarrollo de software.
6
www.monografias.com/modelos/call/call.shtml
12
• Retener el recurso humano dentro de la organización, que se
comprometan y quieran a su empresa y mas que buscar un bienestar o
provecho personal lo busquen para si y para su misma organización.
Nivel 1
En este nivel mas que empezar a introducir o ejecutar procedimientos de
mejora es mas bien analizar si dentro de la empresa se presenta alguno de los
siguientes casos, que obviamente no son positivos o benéficos para la misma
organización.
13
Los puntos a considerar son:
• Distractores ambientales.
• Objetivos de desempeño ambiguos.
• Falta de conocimientos o habilidades relevantes.
• Comunicación pobre entre la fuerza laboral misma, ya sea entre
subordinados o entre subordinados y el jefe.
Nivel 2
En este nivel se busca eliminar los problemas de las organizaciones que se
detectaron en el Nivel Inicial. En cuanto al ambiente de trabajo, esta diseñado
para establecer y mantener condiciones de trabajo que permitan concentrarse
en sus tareas, sin distracciones innecesarias o inapropiadas.
Los objetivos planteados en este nivel son poner a disposición de todos los
empleados los recursos necesarios para que se sientan cómodos y contentos
al realizar su trabajo y por consiguiente el desempeño de los procesos mejóre,
además de evitar distracciones en el mismo lugar de trabajo. Desde el punto
de vista de la comunicación se pretende establecer un ambiente social que
permita una interacción efectiva entre todo el personal de la organización y
asegura que la fuerza de trabajo tiene las habilidades para compartir
información y coordinar sus actividades eficientemente.
14
Para el contrato de personal, se establece y usa un proceso formal por medio
del cual el talento es reclutado, seleccionado sin preferencias de ningún tipo
excepto el de la habilidad y conocimientos intelectuales para desempeñar sus
funciones correctamente. También establece criterios objetivos para medir el
desempeño grupal e individual y da retroalimentación sobre el mismo para así
aumentar el desarrollo de los empleados día con día y evitarse el
estancamiento o el que los procedimientos y metodologías así como la forma
en que se llevan a cabo los procesos se vuelvan obsoletos.
Nivel 3
Se enfoca en la creación de una estructura organizacional para el desarrollo de
la fuerza de trabajo. En este nivel la organización identifica el conocimiento y
las habilidades necesarias para la realización de las actividades de negocios
también desarrolla planes estratégicos para que la fuerza de trabajo pueda y se
le facilite cumplir los objetivos planteados por la organización a corto y largo
plazo. Existen también las posibilidades de promoción para alentar a las
personas a desarrollar sus capacidades de la mejor y más productiva manera.
Propone también utilizar las habilidades de cada individuo a la hora de llevar a
cabo los procesos de trabajo para establecer roles que sirvan para dar el
siguiente paso en el desarrollo del mismo grupo de trabajo.
Por ultimo se establece una cultura de participación que permite un mejor uso
del talento de la gente dentro de la organización para tomar decisiones y
realizar de forma más efectiva el trabajo.
15
Nivel 4
Las tareas por realizar en este nivel se enfocan principalmente en explotar el
conocimiento y la experiencia de los trabajadores de la organización que se
logro desarrollar en el nivel 3. Los procesos basados en la aptitud son usados
para crear ahora procesos integrados y multidisciplinarios. Los grupos de
trabajo son autorizados para manejar sus propios procesos de trabajo y dirigir
la mayoría de sus actividades. Los resultados obtenidos son capturados y
reutilizados. Los consejeros o jefes se apoyan en la infraestructura creada en
este nivel para atender mejor a los individuos y grupos de trabajo en el
desarrollo efectivo de sus capacidades.
Nivel 5
Las actividades realizadas en este nivel se enfocan en improvisar y mejorar
continuamente las actividades y los procesos de la organización así como
también las actividades de la fuerza de trabajo. Los individuos
consecutivamente mejoran los procesos de trabajo personales que usan y por
consiguiente el mismo grupo de trabajo mejora sus procesos por tomar mano
de la buena ejecución individual de los mismos, así como también la
organización evalúa y mejora la relación de rendimiento entre individuos,
grupos de trabajo y unidades todos en conjunto y con los objetivos de negocios
de la organización. Por último se evalúan las oportunidades para improvisar y
renovar las prácticas de la fuerza de trabajo mediante la mejora o ajustes
increméntales la adopción de practicas nuevas e innovadoras y por supuesto
nueva tecnología que facilite el desarrollo de las mismas.7
7
www.ingenierosoftware.com/calidad/cmm.
16
puede utilizar como herramienta de evaluación del estado de los procesos de
software de la empresa, además es independiente de la organización, del
modelo del ciclo de viia, de la metodología y la tecnología
Considero este modelo como un marco para métodos de evaluación, no un
método o modelo en sí y abarca los siguientes puntos dentro de la calidad del
software:
• Evaluación de procesos.
• Mejora de procesos.
• Determinación de capacidad.
P Conceptos P Vocabulario
y guía de
1 introducción
9
P
7 P P
Guía para
Guía de uso
para la mejora 8 determinar 6 Guía de
capacidad de calificación de
de procesos proveedores evaluadores
Realización Guía de
de una evaluación
P evaluación P
3 4
17
El modelo SPICE cuenta con un modelo de referencia llamado P2 el cual
describe los procesos que una organización puede realizar para comprar,
suministrar, desarrollar, operar, mantener y soportar el software, así como los
atributos que caracterizan la capacidad de estos procesos, proporciona una
base para medir la capacidad de los procesos, en función de grado de
consecución de sus atributos.
Procesos
Contiene los procesos que se han de evaluar y que corresponden con los
procesos del ciclo de vida del software, definidos en el estándar ISO 12207
creado en 1995.
• CUS: Cliente-Proveedor.
• ENG: Ingeniería.
• SUP: Soporte.
• MAN: Gestión.
• ORG: Organización.
18
• CUS.7 Proporcionar servicio al cliente.
• CUS.8 Valorar la satisfacción del cliente.
La dimensión de procesos SUP está formada por procesos que dan soporte a
cualquiera del resto de procesos (incluidos los SUP), en distintos puntos del
ciclo de vida del software.
• SUP.1 Documentación.
• SUP.2 Gestión de la configuración del software.
• SUP.3 Garantía de calidad.
• SUP.4 Resolución de problemas.
• SUP.5 Realizar revisiones conjuntas.
19
La dimensión ORG se encuentra formada por procesos que establecen los
objetivos de negocio de la organización.
Capacidad
1. Incompleto.
2. Realizado (Realización del proceso).
3. Gestionado (Gestión de realización, Gestión de productos) .
4. Establecido (Definición de procesos, Recursos de procesos) .
5. Predecible (Medición de procesos, Control de procesos).
6. En optimización (Cambio de procesos, Mejora continua).
8
www.ingenierosoftware.com/calidad/spice
20
1.2 CALIDAD DE PROCESO DE INGENIERIA DE SOFTWARE
21
1.3 CALIDAD DEL PRODUCTO DE SOFTWARE
Por lo tanto para lograr la calidad en el producto primero que nada es necesario
comprender desde el principio del proyecto las necesidades reales y completas
de los usuarios con tanto detalle como sea posible (requerimientos) mientras
mas claras y detalladas sean mas fáciles de solucionar e implementar van a
ser.
22
Existen diferentes aspectos de la calidad que seria conveniente tomar en
cuenta:
Calidad externa
e interna
capacidad para
capacidad para
ser entendido
adecuación madurez ser analizado adaptabilidad
capacidad para comportamiento
exactitud tolerancia a capacidad para instalabilidad
ser aprendido temporal
interoperabilidad fallos ser cambiado coexistencia
capacidad para utilización de
seguridad de capacidad de estabilidad capacidad para
ser operado recursos
acceso recuperación capacidad para ser reemplazado
capacidad de
ser probado
atracción cumplimiento de
cumplimiento de cumplimiento de cumplimiento de
la eficiencia
la funcionalidad la fiabilidad cumplimiento de la portabilidad
cumplimiento de
la mantenibilidad
la usabilidad
23
Características del modelo:
FUNCIONALIDAD
FIABILIDAD
24
USABILIDAD
EFICIENCIA
MANTENIBILIDAD
25
Capacidad para ser probado.- Permite que el software modificado pueda ser
validado y probado las veces que resulte necesario.
Cumplimiento de la mantenibilidad.- Capacidad del software de poder ser
mantenido y corregido durante la operación del mismo sin que se altere en
ningún momento.
PORTABILIDAD
Calidad en
Uso
Seguridad de
Efectividad Productividad Satisfacción
acceso
9
www.ideotechnologies.com/calidadexternainterna.html (23/11/2006)
26
Características del modelo:
EFECTIVIDAD
PRODUCTIVIDAD
Capacidad del software para permitir a los usuarios gastar una cantidad
adecuada de recursos con relación a la efectividad alcanzada, en un contexto
de uso especifico.
SEGURIDAD FÍSICA
SATISFACCIÓN
Capacidad del software para satisfacer a los usuarios cumpliendo con todos los
requerimientos que ellos esperaban o solicitaron.
27
que podría ser desarrollado, adquirido, incorporado al sistema y compuesto con
otros componentes, de forma independiente en tiempo y espacio”.
28
La palabra calidad tiene varios significados, una de ellas es la definida por la
Norma ISO 8402 que la define como:
1.3.3.1 CARACTERÍSTICAS
10
www.msguayaquil.com/blogs/julioc/archive/2006/05/08/Desarrollo-de-Software-Basado-en-
Componentes.aspx
29
Siguiendo su terminología, entendemos por característica de calidad de un
producto software a un conjunto de propiedades mediante las cuales se evalúa
y describe su calidad.
30
En este sentido es importante señalar que fundamentalmente este tipo de
atributos van a coincidir con los atributos de calidad que pueden ser medidos
durante la ejecución del sistema o de los componentes.
Sin embargo, suelen ser más al nivel de sistema que de componentes, pues el
QoS se mide con respecto al comportamiento global del sistema y a los
resultados que éste produce.
CALIDAD EN EL PRODUCTO
Por tanto ese modelo se muestra idóneo como base de partida general, pero
que es necesario refinarlo al caso particular de los componentes, al igual que
se hace para otros desarrollos, como pueden ser las páginas Web u otros.
31
Por otro lado, desde el punto de vista de la arquitectura software y dado la gran
relación que con ella tienen los componentes, es destacable el tratamiento que
da Bass a los atributos de calidad dentro de la arquitectura software como otra
propuesta.
Su trabajo presenta una idea muy interesante y que puede ser aplicada a los
componentes, al proponer una clasificación de los atributos de calidad en
función de si tienen relación con la arquitectura de software o no.
32
perspectiva de ingeniería de sistemas de software en general. Estos atributos
son: Rendimiento, Mantenibilidad, Fiabilidad, Seguridad Física y Seguridad de
Acceso.
Por lo tanto cuando todos estos autores hablan de atributos QoS se refieren a
un conjunto de atributos de calidad extra-funcionales que son discernibles
durante la ejecución del sistema y que pueden ser vinculados con un caso de
uso particular.11
11
www.wikipedia.org/wiki/Calidad_del_producto
33
CALIDAD EN EL PROCESO
Los siguientes son trabajos que tratan de forma directa el proceso de desarrollo
basado en componentes y que para este trabajo serian de gran interés:
34
Una de las principales desventajas de este modelo es que no se llega a definir
ningún conjunto de atributos de calidad (es decir, un modelo de calidad), lo cual
limita bastante su utilización práctica). 12
• Cuantificación.
• Examen.
• Especificación.
• Transformación.
• Agregación.
12
www.tpmonline.com/articles_on_total_productive_maintenance/rootcause/calidadprocesocau
saraiz02.htm
35
COTS-Based Requirements Engineering (CRE)
• Identificación.
• Descripción.
• Evaluación.
• Aceptación.
36
Dichos modelos son :
Por otra parte, hoy en día se cuenta con herramientas para producir muchas
más líneas de código y si se mantienen los niveles presentes de calidad, el
cuello de botella se presentará en el esfuerzo de mantenimiento que, en la
actualidad, requiere el apoyar una tasa de desarrollo y producción entre tres y
diez veces más rápida que antes.
Los componentes de tipo resultado son unidades bajo las cuales el usuario o
cliente emite un juicio sobre el producto o servicio. Estas unidades son de
relevancia a la actividad del usuario de informática.
13
www.lcc.uma.es/~av/misConfs/CalidadComponentes-UCLM05.ppt
37
Ejemplos de éstas son: El número de veces que no pudo lograr una venta
porque sus sistemas fallaron o la pérdida de oportunidades de negocio por no
contar con la información pertinente.
Para obtener una definición aceptable de calidad, se hace uso de los conceptos
de métrica y medida. Una medida puede definirse como la evaluación de una
variable de control. Es necesario remarcar que no es fácil hacer deducciones
sobre una medida. Por ejemplo, una medida de un programa es el número de
líneas de código o el tiempo que tarda un usuario en manejar bien el programa.
38
Los resultados que obtiene un ejecutivo basado en opiniones y que toma
decisiones porque «al parecer» una metodología de diseño no está siendo
satisfactoria, son muy distintos a los que llega uno que analiza datos históricos
de varios meses de labores, donde se observan tendencias en métricas.
39
Cuando las características de calidad o propiedad del producto o servicio
contribuyen a su adecuación de uso como el rendimiento y fiabilidad que se
obtiene de un software. La calidad de diseño o la adecuación de las
características de calidad diseñadas para la generalidad de usuarios, es
importante ya que el diseño es parte de cómo el usuario se familiarizara con el
sistema para su mejor desempeño.
Para otros autores como Taylor plantean que los especialistas establecen los
estándares técnicos, los empleados/operarios los cumplen y los supervisores
verifican los resultados una vez terminado el proceso, sin embargo, otros como
Deming destacan la importancia de la flexibilidad en las organizaciones y en la
implementación de la gestión de la calidad total.
40
Así es como podemos tener un amplio conocimiento de lo que es y lo
importante que es obtener la calidad en cada uno de los procesos para
finalmente tenerlo en los productos o servicios a ofrecer en el mercado. Es así
como esta persona dio a conocer el valor que tiene la calidad y lo importante
que es ofrecer un producto garantizado y confiable para su uso.
41
Por tal motivo deben de mejorar constantemente y para siempre en los
procesos de planeación, producción y servicio. Para así poder reducir costos
en los procesos.
Por lo que se sugiere que se tome bien este papel ya que es uno de los más
importantes el ser líder y tener as u cargo un grupo de personas que están
encargadas de desarrollar alguna actividad especifica que forma parte del
proceso.
El miedo también suele ser uno de los más aterradores problemas que puede
tener una organización, ya que con este no se llega a nada bueno si no a
resultados no deseados, por lo que hay que eliminar el miedo para poder tener
un mejor desarrollo y desenvolvimiento dentro de la empresa en cuanto a la
realización de las actividades como también la opinión de cada uno de los
integrantes de la empresa, por que una opinión o varias puede ayudar bastante
a que una organización mejore sus procesos.
14
www.buscarportal.com/articulos/iso_9001_mejora_continua.
42
Mejora
Mejora continua
de la
calidad Calidad total
Garantía
de calidad
Prevenir
defectos
Control de
calidad
Detectar
defectos
Tiempo
15
www.uv.mx/iiesca/revista2000/mejora.htm
43
CAPÍTULO II
PROCESOS DE ADMINISTRACIÓN DE CALIDAD DE SOFTWARE
Dentro de la calidad del software existe una compleja mezcla de factores que
varían dependiendo de la aplicación y el cliente que la solicite.
Para mi la garantía de calidad es una actividad esencial en cualquier empresa
que produce productos que van a ser usados por otros.
44
Antes del siglo XX, la garantía de calidad era responsabilidad única de la
persona que construía el producto. La primera función de control y de garantía
de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendió
rápidamente por todo el mundo de las manufacturas. Actualmente cada
compañía la tiene como táctica de mercado la cual consiste en poner en claro y
recalcar explícitamente el hecho de que su producto cuenta con los más altos
estándares de calidad.
45
Alguna vez una importante empresa de automóviles dijo la frase “la calidad es
el trabajo número 1”, lo cual quiere dar a entender que lograr la calidad de un
producto de software es trabajo de todos aquellos que interactúen con la
misma organización, los ingenieros de software, gestores de proyecto, clientes,
comerciantes.
Los factores que afectan la calidad del software se clasifica en dos grupos:
1.- Factores que pueden ser medidos directamente, por ejemplo errores o
unidad de tiempo.
Factores que solo pueden ser medidos indirectamente como la facilidad de uso
de mantenimiento.
46
Facilidad de Mantenimiento. El esfuerzo requerido para localizar y arreglar un
error de un programa.
47
de la calidad, el control de la calidad, el aseguramiento de la calidad, y la
mejora de la calidad, a continuación se describen tres de ellos.16
Por lo tanto si la palabra aseguramiento crea una idea de confianza sobre algo
entonces el aseguramiento de calidad del software puede definirse como el
conjunto de actividades que se planean y sistematizan antes y durante la
construcción de un software para precisamente asegurar que dicho producto va
a satisfacer los requisitos iniciales del usuario.
16
www.monografias.com/trabajos6/isof/isof.shtml
48
Existen dos actividades principales en las que se lleva a cabo mas visiblemente
el aseguramiento de la calidad de un software
17
www.sma.df.gob.mx/simat2/ponencias/sesion5/aseguramientoycontrolcalidadaireretama.pdf
49
• Mantener bajo control un proceso.
• Eliminar las causas de los defectos en las diferentes fases del ciclo de
vida.
En pocas palabras son las actividades que sirven para evaluar la calidad de los
productos dentro del sistema de calidad de una organización. Por sistema de
calidad se conoce a la estructura organizativa, los procedimientos, procesos y
recursos necesarios para implementar la gestión de calidad mencionada con
anterioridad.
Un sistema de calidad consta de varias partes, las cuales son las siguientes:
Parte física.-
• Locales.
• Herramientas.
• Ordenadores.
Aspectos humanos.-
• Formación de personal.
18
http://es.wikipedia.org/wiki/Sistema_de_control_de_calidad_de_software
50
• Creación y coordinación de equipos de trabajo.
• Normativas.
ISO.-
• ISO 9000: Gestión y aseguramiento de calidad (conceptos y directrices
generales).
• Recomendaciones externas para aseguramiento de la calidad (ISO
9001, ISO 9002, ISO 9003).
• Recomendaciones internas para aseguramiento de la calidad (ISO
9004).
• MALCOLM BALDRIGE NATIONAL QUALITY AWARD(Premio Nacional
de Calidad Malcolm Baldrige).
2. A veces se ejecuta:
En puntos de revisión ligados a las etapas del ciclo de vida del desarrollo del
SW, particularmente antes del pase a producción.
Bajo un conjunto de rígidos patrones (check list) cuya revisión suele consumir
demasiado tiempo y se genera un retraso.19
19
www.qualitrain.com.mx/controldecalidad.index.php
51
2.4 CERTIFICACIÓN DE LA CALIDAD
Una de las principales amenazas para la calidad del software viene de los
cambios. Cada cambio realizado sobre el software en potencia puede introducir
errores o crear efectos laterales que propaguen errores. El proceso de control
de cambios contribuye directamente con la calidad del software, al formalizar
las peticiones de cambio, evaluar la naturaleza de cambio y controlar la
naturaleza de cambio.
52
Los objetivos de la reunión técnica formal son :
20
Sanders 94, p. 44
53
Otra de las actividades de la garantía de calidad es la Seguridad del
Software.
54
anteriores. La validación es una tentativa de asegurarse de que el producto
está bien construido, es decir, el producto satisface su propósito previsto
específico.
El plan que resulta documenta y describe los roles y actividades, así como las
técnicas y las herramientas que se utilizarán. Una comprensión de los diversos
propósitos de cada actividad de V&V ayudará en el planeamiento cuidadoso de
las técnicas y de los recursos necesitados para satisfacer futuros propósitos. 21
21
www.emagister.com/calidad-software-tps-963351.htm
55
Existen varios criterios para evaluar un software y definir si conviene adquirirlo,
o si fue bueno o malo. Aunque claro para poder catalogar un software como
bueno o funcional, el mismo debe responder a diversos aspectos como
técnicos, pedagógicos, metodológicos y funcionales.
Algunos de los criterios que podemos tomar en cuenta son los siguientes:
Versatilidad
56
Navegación
Efecto del
Recursos y Proceso de Producto
producto
entorno evaluación software
software
14598-1
Proceso de evaluación
14598-4
14598-6 9126-3 9126-2 9126-4
14598-5
Figura No. 7 Evaluación del producto
57
Proceso de evaluación del producto
58
positivo como negativo cuando está en uso; decidir cuando mejorar o
reemplazar un producto.
Requerimientos Operación
uso y respuesta
determina
Especificación
indica Pruebas
determina
Diseño y
Desarrollo
indica
59
Establecer niveles de puntuación para las métricas
valor
satisfactorio
medido Rango objetivo
nivel actual
Mínimamente aceptable
el caso peor
insatisfactorio
Inaceptable
60
Necesidad de construir un producto con integridad.
• Gestionar el proyecto
• Desarrollar el producto
• Cautelar las propiedades del producto
61
para la predicción de costos (por supuesto, las mediciones de la calidad del
producto software pueden usarse para estos fines).
Proceso de evaluación:
La serie de normas UNE 71048 proporciona los requisitos y una guía para el
proceso de evaluación en tres situaciones distintas:
62
Proceso para desarrolladores: La norma UNE 71048-3 debe usarse por
organizaciones que proyectan el desarrollo de un nuevo producto o la mejora
de un producto existente y pretenden realizar la evaluación del producto
utilizando los miembros de su propia plantilla de técnicos. Se centra en el uso
de aquellos indicadores que pueden predecir la calidad del producto final
mediante la medición de productos intermedios creados durante el ciclo de
vida.
Proceso para adquisidores: La norma UNE 71048-4 debe usarse por las
organizaciones que proyectan adquirir o reutilizar un producto software
existente o pre-desarrollado. Puede aplicarse para decidir sobre la aceptación
del producto o para la selección de un producto de entre varios alternativos.
(Un producto puede ser auto-contenido, ser una parte de un sistema, o puede
ser parte de un producto mayor).
Proceso para evaluadores: La norma UNE 71048-5 debe usarse por los
evaluadores que lleven a cabo una valoración independiente de un producto
software. Esta evaluación podría realizarse bajo petición de un desarrollador,
adquisidor u otros. Esta parte está destinada a aquellos que realizan
evaluaciones independientes. Con frecuencia trabajan para terceros.
22
www.is.ls.fi.upm.es/udis/docencia/erdsi/Documentacion-Evaluacion-6.pdf
63
2.6.2 INSPECCIONES
64
Una revisión es una forma de aprovechar la diversidad de un grupo de
personas para:
Comúnmente se ha notado que los defectos o fallas que son lo mismo dentro
de un software se presentan o descubren justamente ya que el producto ha
sido entregado al usuario, esto obviamente es un error y un problema de
calidad del software, por lo tanto el principal objetivo de las inspecciones es
precisamente ese, el descubrir los fallas y/o defectos antes de que el producto
sea entregado.
Por medio de varios estudios como el TRW, Nippon Electric y Mitre Corp., entre
otros se ha demostrado que las inspecciones son efectivas en un 75% a la hora
de detectar errores. Con la detección y la eliminación de un gran porcentaje de
errores, el proceso de inspección reduce substancialmente el costo de los
errores en las fases de desarrollo y mantenimiento.
65
2.6.2.1 EL PROCESO DE INSPECCIÓN
Las inspecciones podría decirse que son un repaso detallado de lo que se esta
haciendo, generalmente se realizan de la siguiente manera, un pequeño grupo
de personas también llamados inspectores revisa un producto de trabajo,
entiéndase por grupo de trabajo 200 líneas de código, o requerimientos, o
diseño entre otros, ya que revisaron esos productos de trabajo se reúnen todos
los grupos y se revisa en conjunto los defectos encontrados. Los productos de
trabajo son considerados en progreso hasta que la inspección y las
correcciones necesarias estén completas.
4.- Examen: En esta etapa, los inspectores se reúnen para analizar su trabajo
individual en forma conjunta. El moderador deberá asegurarse que todos los
inspectores están suficientemente preparados.
66
La persona designada como lector presenta el ‘producto de trabajo’,
interpretando o parafraseando el texto, mientras que cada participante observa
en busca de defectos.
5.- Retrabajo: El autor corrige todos los defectos encontrados por los
inspectores.
Roles: Además del autor se deberá tener en cuenta al moderador quien dirige
la inspección y deberá contar con mayor experiencia que el resto, el lector
quien presenta los productos de trabajo en las reuniones y el escriba quien
documenta la descripción y ubicación de los defectos encontrados.
23
Fagan 1986, pag 254,Limusa.
67
Productos de trabajo: El proceso de inspección puede ser aplicado a diferentes
tipos de productos de trabajo que pueden encontrarse en un desarrollo de
software incluyendo requerimientos, diseño, código, test, guías de usuario y
otro tipo de documentación. El estándar de la IEEE no especifica un tamaño ,
pero los productos de trabajo tienen un tamaño de 10 a 20 hojas para
especificación de requerimientos, 200 o 250 líneas de código.
24
www.monografias.com/trabajos6/isof/isof.shtml
68
2.6.3 RECORRIDOS COMPLETOS
Encontrar anomalías.
Mejorar el producto.
Considerar diferentes alternativas de implementación.
Evaluar conforme a estándares y especificaciones.
Los recorridos completos son similares a las inspecciones solo que se llevan a
cabo de manera menos formal. Los recorridos completos son primeramente
organizados por el ingeniero de software para dar a sus compañeros de equipo
la oportunidad de revisar el trabajo y asegurar y evaluar su técnica. 25
2.6.4 AUDITORIAS
25
www.emagister.com/auditoria-calidad-software-tps-1413086.htm
69
Una de las razones por las que las organizaciones no maximizan su inversión
en activos de software es que no hay información exacta disponible. La
recopilación de toda la información necesaria es un proceso intenso,
especialmente cuando se hace por primera vez. Otro problema es que la
perspectiva de una auditoría puede ser vista con algunas reservas por algunos
directivos de la organización, preocupados porque pueda interrumpir el flujo de
trabajo, y por algunos usuarios finales que pueden ser forzados a abandonar
sus programas o procedimientos favoritos.
Una de las formas de evitar las objeciones y dejar de lado estos problemas es
planificar cuidadosamente la Auditoría de Software y comunicar su valor por
adelantado.
Por lo tanto recomiendo los siguientes factores como elementos que podrían
favorecer notablemente la colaboración entre la gerencia y el personal a través
del proceso de planificación, el cual es una llave para el éxito de cualquier
auditoria de software.
70
Al realizar una auditoria será necesario buscar cada pieza de software en la
organización, pero afortunadamente existe una gran cantidad de herramientas
para automatizar la tarea. Este proceso puede ser en su mayor parte manejado
con soluciones de software, especialmente si los sistemas de información de la
organización están centrados en una o más redes, o las aplicaciones de
software se comparten en la red.
26
www.samsistemas.com.ar/servicios_especiales/auditoria_de_software.html
71
CAPÍTULO 3
CONSIDERACIONES PRÁCTICAS
72
Sommerville , afirma que la mejor forma de asegurar que los requerimientos de
calidad sean verificables, es expresándolos cuantitativamente.
Los requerimientos del software son una descripción abstracta de los servicios
que el sistema debería proporcionar al cliente, y las limitaciones bajo las cuales
éste debería operar.
73
La especificación o análisis de estos requerimientos puede hacerse de manera
formal (utilizando modelos matemáticos) o no formal (a través de modelos
que representan las dimensiones de: datos, comportamiento y funcionalidad).
De esta manera, las especificaciones de los requerimientos constituyen el
punto de partida para lograr el acuerdo del equipo de desarrollo acerca del
alcance del esfuerzo; y forman la base para la definición del diseño o la
arquitectura del software, así como los casos de prueba correspondientes.
Los tres primeros pasos son descritos con detalle en la norma, el cuarto hace
una referencia a la serie de normas ISO/IEC 14598 y el quinto presenta un
comentario sencillo y directo sobre como realizar la evaluación.
27
www.ewh.ieee.org/reg/9/etrans/vol4issue2April2006/4TLA2_6Davila.pdf
74
Los pesos representan la valoración comparada entre las distintas
características y sub características y para ello se puede utilizar una calificación
relativa de alto / medio / bajo o una calificación basada en valores que puede ir
entre 1 y 9.
28
www.monografias.com/trabajos6/resof/resof.shtml(15/06/2007)
75
El usuario es un actor importante en la determinación de los requerimientos de
calidad y su punto de vista debe ser sistemáticamente obtenido.
76
Estos objetivos primarios de DReC coinciden con los tres primeros pasos
establecidos por la ISO/IEC 9126 descrito en la sección anterior.
Anteriormente se dio una visión general de lo que es esta técnica, ahora vamos
a describirla mas a fondo.
77
puede ser omitido si la organización desarrolladora tiene la lista de
componentes por alguna actividad previa a la aplicación de DReC.
78
La hoja de cuestionario se ha elaborado a partir de las definiciones
proporcionadas en la norma ISO/IEC 9126-1: 001 y se compone de 33
preguntas. El resultado deste paso es un modelo de calidad con los pesos
definidos a nivel de características y sub-características.
Paso 2a. Completar la hoja inicial (DReC00) marcando con una "x" de acuerdo
a cada línea que describe una característica o sub característica. La hoja es
completada por todas las personas convocadas: usuarios y desarrolladores.
Paso 2b. Consolidar la información de todos los participantes, de preferencia
de manera automática usando hojas de cálculo o un producto software ad-hoc
para esta actividad de modo que sea rápido y con resultados confiables.
Paso 2c. Revisar los resultados obtenidos y discutir sobre las respuestas cuya
variación sea significativa hasta encontrar Un consenso entre todos los
participantes de la sesión, la participación será mediante un director de debate.
Se podrá utilizar adicionalmente las hojas “DReC11” y “DReC12” siempre que
se cuente con datos históricos.
Paso 3: Definir los niveles de calidad esperado en los atributos del producto, el
objetivo de este paso es la determinación de los valores a ser usados como
nivel de referencia para las métricas en la evaluación, obtenidos
sistemáticamente mediante la aplicación de un conjunto de cuestionarios que
se aplicarán a cada componente seleccionado en el paso 1.
79
de opinión sobre el nivel de calidad requerido. Igual que en el paso anterior, los
participantes son usuarios y desarrolladores, y los cuestionarios están
orientados a los usuarios.
Paso 3a. Completar la hoja “DReC01” y “DReC02” marcando con una "x" de
acuerdo a cada línea que describe un atributo. La hoja es completada por todas
las personas convocadas: usuarios y desarrolladores
Paso 3b. Consolidar la información de todos los participantes, de preferencia
de manera automática usando hojas de cálculo o un producto software ad-hoc
para esta actividad de modo que sea rápido y con resultados confiables.
Paso 3c. Revisar los resultados obtenidos y discutir sobre las respuestas cuya
variación sea significativa hasta encontrar un consenso entre todos los
participantes de la sesión, la participación será mediante un director de debate.
Se utilizarán adicionalmente las hojas “DReC21” y “DReC22”.
Paso 3d. Repetir los sub-pasos anteriores para los pares de hojas “DReC03”-
“DReC04” y “DReC05”- “DReC06”.29
29
www.qualitrain.com.mx/procesos/out_req.php
80
para la organización usuario como desarrolladora, y para almacenar los niveles
reales de calidad logrados en dicho proyecto.
DReC se debe aplicar en dos etapas principales: una que cubra el paso 1 y
otra que cubra los pasos 2 y 3 en conjunto.
30
dmi.uib.es/~bbuades/calidad/calidad.PPTv
81
Para el paso 2 y 3 se convoca a un conjunto de personas entre usuarios y
desarrolladores de modo que realicen las actividades indicadas para cada
componente. Se debe tener en cuenta que para cada componente podría
definirse un equipo diferente de personas quienes completen las actividades;
ello dependerá del componente en sí mismo.
31
www.ingenierosoftware.com/calidad/cmm-cmmi-nivel-2.php
82
La información en estos factores influye para saber cómo están organizados y
documentados los procesos de SQM y que tan especificas son las actividades
escogidas para los mismos, así como los recursos que se van a necesitar, y el
esfuerzo que llevara.32
3.3 SERIEDAD
En los casos donde el fracaso del sistema puede tener consecuencias muy
severas, la seriedad en general (hardware, el software, y el humano) es el
requerimiento principal de la calidad más allá de la funcionalidad básica. La
seriedad del software incluye tales características como la critica, la tolerancia,
la seguridad, y el valor práctico.
32
alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/rodolfo.pdf
33
www.planetacodigo.com/wiki/glosario:nivel_de_integridad
83
La historia del fracaso de software semejante puede ayudar también a
identificar que técnicas serian más útiles para discernir los defectos y valorar la
calidad. 34
Cuando los nuevos métodos de diseño y las lenguas evolucionan, junto con
avances en tecnologías de software totales, nuevas clases de defectos
aparecen, y requieren mucho esfuerzo para que se interpreten clases antes
definidas. Rastreando defectos, el ingeniero de software está interesado no
sólo en el número de defectos sino también en los tipos de defectos.
34
www.monografias.com/trabajos6/resof/resof.shtm
84
Generalmente la palabra “defecto” es usada o se refiere a una falta, sin
embargo, las diferentes culturas y estándares pueden usar diferentes
significados para estos términos, por ejemplo:
Una acción probable que resulta de conclusiones SQM es que se eliminen los
defectos del producto en el examen.
Otras acciones permiten alcanzar de lleno los objetivos del proyecto a partir de
las conclusiones de actividades SQM. Estas acciones incluyen el análisis y el
resumen de las conclusiones, y la utilización de técnicas de medición para
mejorar el producto así como el rastreo de los defectos y su eliminación.
85
Cuándo se automatizan algunas de las herramientas que son utilizadas en este
proceso, la misma automatización de la herramienta puede proporcionar la
información del defecto.
Los datos acerca de los defectos pueden ser reunidos y pueden ser registrados
en un SCR (reporte de cambios de software) los cuales se almacenan en la
base de datos para posteriores análisis, dichos informes acerca de defectos
son proporcionados a la administración de la organización.35
35
www.infor.uva.es/~manso/calidad/Cuestionesmedicion.pdf
86
3.6.1 TÉCNICAS ESTÁTICAS
36
www.portal.educ.ar/noticias/educacion-y-sociedad/metodos-y-tecnicas-de- aseguramiento
87
realizadas sobre la arquitectura. Son utilizadas para medir la complejidad del
sistema, determinar la propensión de fallas de los módulos, etc.37
37
www.sqs.es/es/(03/06/2007)
38
www.usabilidadweb.com.ar/metodos_eval_calidad_web.php
88
3.6.4 TÉCNICAS ANALÍTICAS
Otro, más formal, son los tipos de técnicas analíticas conocidas como métodos
formales. Estos son utilizados para verificar software, los requerimientos y los
diseños. La prueba de la exactitud se aplica a partes críticas del software. Por
eso estos métodos han sido utilizados en su mayor parte en la comprobación
de partes cruciales de sistemas críticos, y los requerimientos más específicos
como los de la seguridad. 39
39
www.sqs.es/es/tecnicasevaluacion
89
3.6.5 TÉCNICAS DINÁMICAS
La lectura del código se considera una técnica estática, pero existen ingenieros
bastante calificados o expertos en su trabajo que pueden leer el código así tal
cual como se les presenta, en este sentido, la lectura de código se puede
calificar también como una técnica dinámica.
3.7 PRUEBA
Esta confirmación también incluye las salidas de los procesos del desarrollo y
del mantenimiento, la recopilación, el análisis, y la medición de los resultados.
La SQA se asegura de que los tipos apropiados de pruebas estén planeados,
convertidos, y puestos en ejecución adecuadamente, y V&V desarrolla los
planes de prueba, las estrategias, los casos de estudio y los procedimientos.
40
www.sqs.es/es/tecnicaevaluacion
90
Dos tipos de prueba pueden caer bajo los títulos de SQA y V&V, debido a su
responsabilidad dentro de la calidad al elegir los materiales usados en el
proyecto:
Existen otros tipos de pruebas de software por ejemplo las pruebas dinámicas,
de unidad, de integración, entre otras. A continuación se muestra una
clasificación de las mismas.
91
3.7.1 CLASIFICACIÓN DE PRUEBAS DEL SOFTWARE
92
Por el contrario, un defecto puede producirse por causas ajenas a las
herramientas.
93
Debugging: Proceso de diagnosticar la causa de un bug y corregirlo.
Es una actividad de corrección y no de testeo.
94
3.7.2 MARCO DEL TESTEO
Caja blanca
95
Gráficamente, se tiene la siguiente visión:
Caja negra
En este método para derivar los casos de prueba se examinan solamente los
requerimientos funcionales del programa.
·
Comprende las técnicas de:
• Prueba de valores límite.
• Particiones de equivalencia.
• Prueba por comparación.
96
3.7.4 TIPOS DE PRUEBAS DINÁMICAS
Prueba de unidad
Prueba de integración
Esta prueba verifica las interfaces entre las partes de un sistema es decir entre
sus módulos, componentes o subsistemas. La integración en esta prueba
puede ser total (Big Bang) o gradual:
97
Gráficamente esta prueba se representa asi:
Prueba de sistema
Esta prueba verifica el sistema global contra sus objetivos iniciales además
recomienda que también se testeen los siguientes conceptos:
• Volumen
• Instalabilidad
• Operabilidad
• Seguridad
• Performance
98
Prueba de aceptación
Prueba de regresión
41
www.grupocobos.com.mx/zrc/pruebas.htm
99
• Criterios de aprobación de la prueba.
• Criterio de clasificación de severidad de bugs.
• Ambientes, recursos físicos y herramientas a utilizar.
• Recursos humanos, responsabilidades y cronograma.
• Función a testear.
• Condiciones a testear.
• Resultado esperado.
• Archivos.
• Scripts.
• Formularios.
• Tarjetas.
100
Análisis y evaluación: Se analizan los resultados obtenidos y en base a los
criterios establecidos en la planificación se determina lo siguiente:
Por todo lo anterior podemos decir que las pruebas ayudan a elevar la calidad
del software, previniendo que los defectos pasen a los usuarios finales,
obviamente este proceso de pruebas no es gratuito y se le debe dedicar un
esfuerzo considerable a su implementación.
Este proceso de pruebas no es trivial y debe planificarse, controlarse y
asignarle recursos altamente calificados, porque cuanto antes se detecte un
defecto, más barato resultará su corrección.
42
www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/calidad.htm
101
Con la sofisticación creciente del software, las preguntas de la calidad van más
allá de si o no los trabajos de software logran las metas mensurables de la
calidad.
Las que se basan en las estadísticas (por ejemplo, Análisis de Pareto, cartas
de funcionamiento, diagramas de la dispersión, distribución normal),las mismas
pruebas estadísticas por ejemplo, la prueba binomial, la predicción del análisis
de la tendencia de la prueba, por ejemplo, los modelos de la confiabilidad.
43
Fenton y Pfleeger, 1997, p. 5, Mc Graw Hill.
102
El fundamento de la teoría representacional consiste en que toda medición
debe asegurar una adecuada representación del atributo real medido mediante
los símbolos o números asignados. Una representación por medición de un
atributo de una entidad es adecuada si es coherente con la idea conceptual
que sobre dicho atributo se tiene.
Así, los datos obtenidos como medidas deben representar los atributos de las
entidades reales que se pretenden caracterizar y el manejo de dichos datos
deben preservar las relaciones que existen entre dichas entidades. Para
establecer medidas se debe partir de la observación del mundo real o dominio.
Se deben identificar cuáles son las entidades que se van a medir por ejemplo el
código y definir qué atributo se desea caracterizar ejemplo de ello la longitud
del código. Además, es importante identificar las relaciones empíricas que se
pueden establecer entre las entidades reales en relación con el atributo que
interesa.
Hay que señalar que no siempre las ideas sobre los atributos o sobre las
relaciones empíricas están tan claras o no hay un consenso sobre ellas.
103
de la representación pero que pueden ser analizadas para mejorar la
comprensión sobre el mundo real.
Es posible que tras acumular datos de este tipo se pueda llegar a definir una
medida formal. Por otra parte, debemos recordar que se podrían establecer
múltiples representaciones para un mismo sistema de relaciones empíricas
104
En la actualidad las propuestas de medidas no suelen tener en cuenta su
validación teórica. Por ello, es especialmente importante tanto que las nuevas
medidas sean analizadas y validadas desde el punto de vista teórico de la
medición además de realizar estudios sobre si las medidas ya existentes
respetan los principios básicos de la medición.
En este sentido hay que diferenciar, por una parte, la medida de la calidad del
texto incluido en un documento, la calidad de la interfase del documento con el
usuario, la calidad de la estructura del documento, sobre todo en documentos
de hipertexto o hipermedia, y, por otro lado, la calidad de los diagramas o
modelos que aparecen en ellos como consecuencia de haber aplicado alguna
metodología de desarrollo de software.
44
www.abits.com.co/productos/lenguajes.asp
105
3.8.2 MÉTRICAS EN LA REUTILIZACIÓN ORIENTADA AL OBJETO
106
b)La vertiente de proceso, encargada de los aspectos de gestión y
metodología
PROCESO
El desarrollo de productos software con un alto valor de reutilización supondrá
un incremento de los costos, ya que esto resultará un valor añadido. El modelo
de costes que se utilice deberá incluir de una u otra forma parámetros que
reflejen ese valor añadido al producto. 45
En cuanto a los costos del desarrollo con reutilización se estiman un poco mas
elevados ya que éste es uno de los aspectos más conflictivos de la
reutilización. Los modelos de estimación de costos deberán diferenciar entre
elementos software que se desarrollan por completo y aquellos que se
reutilizan de manera parcial o total.
45
Karlsson, 1995, pp165-168] [Frakes, 1996.LIMUSA
107
En base a esto cabe esperar una reducción en los costos, pues desarrollar con
reutilización debe aumentar la productividad. Sin embargo no todos los autores
coinciden en este punto, según los beneficios de la reutilización hay que
buscarlos en la mejora de otros aspectos como calidad, fiabilidad, etc. y no en
los costos.
PRODUCTO
Las métricas servirán para reflejar y/o controlar, entre otros, la reusabilidad y
factores de calidad que sean de interés en el entorno de desarrollo para
reutilización. Es un hecho que las personas que juegan el papel de
desarrolladores para reutilización, deben poner el máximo interés para que los
assets que producen recuperen la inversión de tiempo y dinero a través de su
reutilización, y las métricas son un medio para cualificar los assets que están
produciendo.
Las métricas del producto son parte de las herramientas a utilizar en este
proceso; y modelos como el FCM(Factor, Criterios, Métricas) o el
GQM(Objetivos, Cuestiones, Métricas), permitirán crear un marco en el que
deducir un conjunto de métricas asociadas a cada factor u objetivo de interés.
108
La explotación del repositorio, en el desarrollo con reutilización, permitirá
obtener información procedente de los usuarios, que puede dar lugar a
revisiones y ajustes en ese conjunto de métricas. El marco que proporcionan
los modelos bayesianos pueden facilitar algunos reajustes, considerando que
permiten realizar modificaciones en las estimaciones a priori, con la llegada de
nueva información. 46
Así pues podemos decir que las métricas o mediciones ya sea para el proceso
de desarrollo de software, como para la documentación, como para
programación tradicional y orientada a objetos y ahora también dentro de la
creación de software para la reutilización son y serán instrumentos que nos
ayuden a tener una visión más amplia de cómo van y como salieron las cosas
al final del trabajo.
Existen muchos y variados métodos para medir, pero al final todos llegan a la
misma conclusión solo que siguiendo diferentes caminos. Muy probablemente
las métricas las entendamos mejor en el momento mismo de aplicarlas y
observar sus resultados, pero en este trabajo se muestra la información
necesaria para precisamente poder aplicarlas y sobre todo se indica el porque
de medir.
46
McClure, 1997, pp. 158-162, LIMUSA
109
CONCLUSIÓN
La calidad del software como ya hemos visto es un tema que ninguna empresa
puede dejar pasar desapercibida si es que quiere lograr crecer y vender su
producto, mucho mas ahora que vivimos en un mundo de competencia
excesiva en el que de cada producto hay 20 del mismo tipo y por lo que solo la
calidad de cada uno hace la diferencia para el cliente.
La calidad del software para mi, mas que una etapa dentro del ciclo de vida del
software es como un paso primordial dentro de cada etapa, es decir, cada nivel
del ciclo desde la definición del requerimiento hasta su mantenimiento debe
realizarse con una calidad total ya que de cada una de estas etapas dependerá
la entrega de un producto que cubra y satisfaga al máximo la necesidades y
exigencias del cliente.
Afortunadamente en la medida que crece la necesidad de generar dentro de
las empresas el concepto de calidad total también van surgiendo nuevos
modelos y metodologías que nos ayudan a generar un producto de calidad con
procesos de calidad con los cuales resulta más fácil cumplir los requisitos de
calidad que el producto exige.
La calidad es un proceso que puede definirse, implementarse, administrarse,
medirse y mantenerse, es por eso que actualmente escuchamos mucho
mencionar las normas de calidad, las certificaciones de calidad y los sellos de
calidad que le dan renombre a las empresas y por los cuales se enfocan tantos
esfuerzos en alcanzarla, estas revisiones son cada año y las certificaciones son
aproximadamente cada 3 años por lo tanto mientras mejores sean los procesos
de calidad de las empresas mejores y mas satisfactorias resultaran.
110
BIBLIOGRAFÍA
CAPÍTULO 1
111
• www.rincondelvago.com/control-de-calidad_ti13.html
• www.gestiopolis.com/canales/gerencial/TI_calidad
CAPÍTULO 2
• www.monografias.com/trabajos6/isof/isof.shtml
• www.infoforhealth.org/pr/prs/sj47/j47chap2_3.shtml
• www.sma.df.gob.mx/simat20/ponencias/sesion5/aseguramiento_y_contr
ol_calidadaire_retama.pdf
• www.elprisma.com/apuntes/curso.asp
• www.mgar.net/soc/isointro.htm
• www.gestiopolis.com/canales/gerencial/articulos/27/asesis.htm
• www.es.wikipedia.org/wiki/Sistema_de_control_de_calidad_de_software
• www.qualitrain.com.mx/index.php
• www.emagister.com/gestion-certificacion-calidad-software-sistemas-
criticos-aeronautica-espacio-cursos-2467459.htm
• www.emagister.com/calidad-software-tps-963351.htm
• www.is.ls.fi.upm.es/udis/docencia/erdsi/Documentacion-Evaluacion-6.pdf
• www.eprints.rclis.org/archive/00002231/01/aci05395.htm
• www.lisi.usb.ve/publicaciones/
• www.inei.gob.pe/web/metodologias/attach/lib608/cap10-3.htm
• www.acuavalle.gov.co/docs/contratacion/EVALYCALIFTECNICAModern
Software25Sp07.pdf
• www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/DIEZ-
INSPECCIONES.pdf
• www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/DIEZ-
INSPECCIONES.pdf
• www.samsistemas.com.ar/servicios_especiales/auditoriadesoftware.html
• www.emagister.com/auditoria-calidad-software-tps-1413086.htm
112
CAPÍTULO 3
• www.ewh.ieee.org/reg/9/etrans/vol4issue2April2006/4TLA2_6Davila.pdf
• www.monografias.com/trabajos6/resof/resof.shtml
• www.qualitrain.com.mx/procesos/out_req.php
• www.ingenierosoftware.com/calidad/cmm-cmmi-nivel-2.php
• www.alarcos./doc/ISOFTWAREI/rodolfo.pdf
• www.planetacodigo.com/wiki/glosario:nivel_de_integridad
• www.infor.uva.es/manso/calidad/Cuestionesmedicion.pdf
• www.dcc.uchile.cl/web/article-15878.html
• www.portal.educ.ar/noticias/educacion-y-sociedad/metodos-y-tecnicas-
de-aseguram.php
• www.sqs.es/es/
• www.usabilidadweb.com.ar/metodos_eval_calidad_web.php
• www.grupocobos.com.mx/zrc/pruebas.htm
• www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/calidad.htm
• www.abits.com.co/productos/lenguajes.asp
• www.grupocolumbia.com/frame_prueba.htm
• www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-
software
• www.um.es/informatica/estudios/programas/ITIG/06BE.pdf
• www.estrasol.com.mx/acl.php
• www.giro.infor.uva.es/Publications/2004/MLC04/JENUI2004.pdf
• www.wikipedia.org/wiki/Pruebas_de_software
• www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-
software.shtml
• www.pruebasdesoftware.com
• www.iti.upv.es/services/formacion/cursos/list/espec_testeo
• www.sc.ehu.es/jiwdocoj/remis/docs/mmg-2000.ppt
• www.oei.eui.upm.es/Asignaturas/PInformaticos/ficheros/transparencias
• www.sc.ehu.es/jiwdocoj/remis/docs/mmg-2000.ppt
• www.inei.gob.pe/biblioineipub/bancopub/inf/Lib5042/cap20.htm
113