APUNTES DE LA MATERIA

CALIDAD EN LOS SISTEMAS DE

INFORMACION

INSTITUTO TECNOLOGICO DEL

ISTMO

ACADEMIA DE SISTEMAS Y
COMPUTACION

LIC. JESUS LOPEZ CHIRINOS

1
 INDICE

Presentación………………………………………………………………..1
Indice………………………………………………………………..............2
Unidad 1 Conceptos básicos de calidad…………………………………4
1.1 Definición de calidad.......................................................................5
1.2 Definición de control de calidad……………………………………....6
1.3 Definición de calidad de sistemas de información………………….7
1.3.1 ¿Quién define la calidad?.............................................................9
1.4 Importancia de la calidad……………………………………………...10
1.4.1 La calidad y el mundo globalizado…………………….…………..11
1.4.2 Compromiso total con la calidad………………………..………….12
1.4.3 El aumento del riesgo asociado a la poca calidad…….…………16
1.5 Calidad total………………………………………………….…………17
Unidad 2 Calidad enfocada al desarrollo de sistemas de información.18
2.1 Calidad en los sistemas de información……………………………..19
2.2 Defectos y errores de calidad en los sistemas de información…...21
2.2.1 El cuaderno de registro de defectos……………………………….23
2.2.2 Contabilización de defectos y errores……………………………..25
2.2.3 Formas de encontrar y corregir defectos………………………….27
2.2.4 El costo de encontrar y corregir defectos…………………………28
2.3 Listas de comprobación……………………………………………….29
2.4 Gestión del tiempo para el desarrollo de sistemas de información.30
2.5 Obtener calidad de los sistemas de información…………………...32
2.6 Controlar la calidad de los sistemas de información……………….33

2
2.7 Costo de la calidad en los sistemas de información………………34
2.7.1 Cálculo del costo de la calidad……………………………………35
Unidad 3 Aseguramiento de la calidad de los sistemas de información
(SQA)……………………………………………………………36
3.1 La función de aseguramiento de la calidad…………………………37
3.2 Relación de la ingeniería de software SQA………………………..38
3.3 Definición y propósito SQA……………………………………………40
3.4 Problemas que resuelve SQA………………………………………...42
3.5 Ciclo de vida del software……………………………………………..43
3.6 Roles y responsabilidades de los equipos de desarrollo…………50
3.7 Habilidades y capacidades del personal del SQA…………………52
3.8 Actividades del SQA…………………………………………………..54
3.6.1 Roles y responsabilidades del equipo de desarrollo…………….57
3.7.1 Habilidades y capacidades del personal SQA……………………63
Unidad 4 Nomenclatura y certificación de ISO 9001:2000…………….66
4.1 La norma ISO 9001…………………………………………………….67
4.2 La norma ISO/IEC 9126……………………………………………….69
4.3 Características deseadas del modelo Moprosoft…………………..74
4.4 Fase especificación de requerimientos……………………………...80
4.5 Fase de análisis y diseño……………………………………………..81
4.6 CMMI……………………………………………………………………83
4.7 Tendencias actuales aplicadas a la calidad en los sistemas de -
Información…………………………………………………………….88

3
 UNIDAD 1
CONCEPTOS BASICOS DE CALIDAD

4
1.1.- DEFINICION DE CALIDAD

La calidad es una propiedad inherente de cualquier cosa que permite que esta sea
comparada con cualquier otra de su misma especie.

La palabra calidad tiene múltiples significados. Es un conjunto de propiedades inherentes a

un objeto que le confieren capacidad para satisfacer necesidades implícitas o explicitas. La
calidad de un producto o servicio es la precepción que el cliente tiene del mismo, es una
fijación mental del consumidor que asume conformidad con dicho producto o servicio y la
capacidad de sí mismo para satisfacer sus necesidades. Por tanto, debe definirse en el
contexto que se esté considerando.

La calidad se suele definir como el cumplimiento de los requisitos, ya sea que estos sean
implícitos o explícitos, para la satisfacción de un cliente. Diferentes clientes pueden tener
diferentes conjuntos y niveles de requisitos respecto de una misma categoría de productos o
servicios. Es por ello que la definición de requisitos, debe de realizarse para un cliente o
conjunto de clientes en particular.

Y para ello, antes de definir los requisitos de un producto, debe necesariamente definirse al
cliente para el cual va destinado. La calidad también involucra que la productividad, la
rentabilidad y la aceptación en el mercado sean proporcionales al nivel de satisfacción del
cliente.

5
1.2.- DEFINICION DE CONTROL DE CALIDAD

La función del control de calidad existe primordialmente como una organización de servicio,
para conocer las especificaciones establecidas por la ingeniería del producto y proporcionar
asistencia al departamento de fabricación, para que la producción alcance estas
especificaciones. Como tal, la función consiste en la recolección y análisis de grandes
cantidades de datos que después se presentan a diferentes departamentos para iniciar una
acción correctiva adecuada.

Para controlar la calidad de un producto se realizan inspecciones o pruebas de muestreo para

verificar que las características del mismo sean óptimas. El único inconveniente de estas
pruebas es el gasto que conlleva el control de cada producto fabricado, ya que se eliminan
los defectuosos, sin posibilidad de reutilizarlo.

Definición.- El proceso de alcanzar los objetivos de calidad durante las operaciones.

Pasos.-

1.- Elegir qué controlar.

2.- Determinar las unidades de medición.
3- Establecer el sistema de medición.
4- Establecer los estándares de performance.
5.- Medir la performance actual.
6.- Interpretar la diferencia entre lo real y el estándar.
7.- Tomar acción sobre la diferencia.
Mejoramiento de la Calidad.-
Definición.- El proceso para alcanzar niveles de performance sin precedente.
Pasos.-
1.- Probar la necesidad de mejoramiento.
2.- Identificar los proyectos concretos de mejoramiento.
3.- Organizar para la conducción de los proyectos.
4.- Organizar para el diagnóstico o descubrimiento de las causas.
5.- Diagnosticar las causas.
6.- Proveer las soluciones.
7.- Probar que la solución es efectiva bajo condiciones de operación.
8.- Proveer un sistema de control para mantener lo ganado.

6
1.3.- DEFINICION DE CALIDAD DE SISTEMAS DE INFORMACION

La ISO 9000, 14000 y 18000, la define como:

¿Qué es un Sistema de Información? Es un conjunto de elementos que interactúan entre sí

con el fin de apoyar las actividades de una empresa o negocio. El equipo computacional: el
hardware necesario para que el sistema de información pueda operar El recurso humano que
interactúa con el Sistema de Información, el cual está formado por las personas que utilizan
el sistema. Un sistema de información realiza cuatro actividades básicas: entrada,
almacenamiento, procesamiento y salida de información.

La calidad de productos y servicios resulta de las contribuciones para la calidad de varios

individuos con muchas habilidades técnicas, de producción y administrativas diferentes. El
centro para el logro de la calidad es entonces, el compromiso positivo con la calidad que es
fundamental para los programas de control total de la calidad.
Hay muchas formas en que este compromiso evoluciona con la calidad y se logra,
dependiendo sean la historia, políticas, personalidades, recursos, etc., de la compañía.
Lograr un compromiso genuino y generalizado con la calidad es un proceso que tiene muchas
dimensiones, y una es que nunca puede considerarse "terminada". Una fuerza perecedera,
sujeta a retos cambiantes continuamente, demandas e influencias inesperadas de muchos
lugares, el compromiso con la calidad se puede considerar como un programa continuo que
es básico para el control total de la calidad y para los sistemas de calidad total.
Panorama del Compromiso con la Calidad

 DEFINICION CALIDAD DE SOFTWARE

Es el desarrollo del software basado en estándares con la funcionalidad y requerimiento total

que satisfacen los requerimientos del cliente. Procesos de desarrollo, análisis y diseño, son
solo algunos de los componentes que se aglomeran para conformar la ingeniería de software
como disciplina para la creación y mantenimiento de software. Una idea general sobre un
software de calidad es aquel que debería cumplir con los requerimientos funcionales y de
performance además de ser mantenible, confiable y aceptable.

Los atributos de calidad son características que sirven para medir un software.

Los principales son:

CALIDAD DEL SOFTWARE

Uno de los problemas que se afrontan actualmente en la esfera de la computación es la

calidad del software. Desde la década de los 70, este tema asido motivo de preocupación
para especialistas, ingenieros, investigadores y comercializadores de software.

7
¿QUE ES LA CALIDAD DEL SOFTWARE?

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su

utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección,
confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.

La calidad del software es medible y varia de un sistema a otro o de un programa a otro. Un

software elaborado para el control de naves espaciales debe ser confiable al nivel de “cero
fallas”; un software echo para ejecutarse una sola vez no requiere el mismo nivel de calidad;
mientras que un producto de software para ser explotado durante un largo periodo (diez años
o más), necesita ser confiable, mantenible y flexible para disminuir los costos de
mantenimiento y perfeccionamiento durante el tiempo de explotación.

La calidad del software puede medirse después de elaborado el producto. Pero esto puede
resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por
lo que es imprescindible tener en cuenta tanto la obtención de calidad como su control durante
todas las etapas del ciclo de vida del software.

La política establecida debe estar sustentada sobre 3 principios básicos: tecnológicos,

administrativos y ergonómico.

La adopción de una buena política contribuye en gran medida a lograr la calidad del software,
pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

8
1.3.1 ¿QUIEN DEFINE LA CALIDAD?

El usuario define la calidad

Debe entenderse que el usuario es quien define la calidad; debiendo la empresa complacer
a los clientes, y no contentarse solo con librarlos de sus problemas inmediatos, sino ir más
allá para entender a fondo sus necesidades presentes y futuras, a fin de sorprenderlos con
productos y servicios que ni siquiera imaginaban. Este conocimiento ya no debe ser solo del
dominio exclusivo de grupos especiales de una organización; sino que debe ser compartido
y desarrollado por todos los empleados.

Una empresa que define la calidad sin tomar en cuenta a los consumidores corre con el riesgo
de producir bienes y servicios con escasa o nula demanda, ya sea porque los clientes tienen
otras expectativas y necesidades, o bien por que los competidores están generando bienes
con mayor valor agregado.

Por tales motivos es esencial para las empresas practicar tanto la investigación de mercado,
como la inteligencia competitiva.

Los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la

forma en que se aplica la ingeniería del software.

9
1.4.- IMPORTANCIA DE LA CALIDAD

La mala calidad de software desarrollado provoca: insatisfacción y desconfianza del cliente,

además de baja en la demanda y utilidades. En el mercado existen productos de toda calidad
y precio. La calidad del software pude medirse en base a ciertos atributos estándar.

Producir software con calidad, a un costo razonable, produce beneficios tanto para los clientes
como para los desarrolladores.

1.- La mala calidad del software desarrollado provoca insatisfacción y desconfianza del
cliente.

2.- en el mercado existen productos de toda calidad y precio por esta razón es indispensable
para las empresas realizar un software de calidad a un precio razonable y así tener un mayor
prestigio que la competencia.

3.- producir software de calidad a un costo accesible produce beneficios tanto para los clientes
como para los desarrolladores.

4.-un cliente satisfecho con seguridad seguirá requiriendo más funciones y se le venderá más
productos.

10
1.4.1.- LA CALIDAD Y EL MUNDO GLOBALIZADO
Hoy en día las compañías de todo el mundo industrializado reconocen que la calidad
del producto se traduce en ahorro de costos y en una mejora general La industria
de desarrollo de software no es la excepción por lo que en los últimos años se han
realizado intensos trabajos para aplicar los conceptos de calidad en el ámbito del
software. Hablar de calidad del software implica la necesidad de contar con
parámetros que permitan establecer los niveles mínimos que un producto de este
tipo debe alcanzar para que se considere de calidad.
El problema es que la mayoría de las características que definen al software no se pueden
cuantificar fácilmente; generalmente, se establecen de forma cualitativa, lo que dificulta su
medición ya que se requiere establecer métricas que permitan evaluar cuantitativamente
cada característica dependiendo del tipo de software que se pretende calificar.

En este sentido se han realizado muchos trabajos que establecen propuestas para el
establecimiento de los factores cualitativos que afectan la calidad del soflware. Entre los
principales están los factores de calidad de McCall y aquellos propuestos por Hewlett-Packard
(FURPS Funcionalityusability, Reliability; Pertormance, Supportability).

Además se han hecho varios intentos por estandarizar los mecanismos de evaluación de
calidad del software. Entre los principales están la familia de normas ISO 9000 [en especial
la ISO 9001 y la ISO 90D3—2)[5], el modelo de niveles madurez CMM (Capability Maturity
Model)[7]. El estándar para el aseguramiento de planes de calidad del lEEE 7301984 (71, el
plan general de garantía de calidad del Consejo Superior de Informática En un contexto
dinámico y competitivo. la Calidad se ha convertido para las organizaciones actuales en uno
de los pilares para alcanzar el éxito. El mundo globalizado ha permitido que la competencia y
el lluro de conocimiento se incrementen en un ritmo vertiginoso lo que ha traído aparejado
una evolución del cliente. Quien hoy por hoy es mucho más exigente que en tiempos pasados.
Ante este panorama, las organizaciones han adoptado a la Calidad 00m0 una respuesta al
entorno en el que se encuentran inmersas, como una forma de mantener la competitividad y
elevar la productividad, maximizando su rentabilidad Términos como Excelencia, Calidad
Total, Mejora Continua ‘Satisfacción del Cliente y otros se han convertido en vocabulario
habitual de quien forma parte de una organización. Diversos autores han definido a la calidad
de diferentes maneras, pero la gran mayoría coincide en un punto fundamental Calidad en
una organización supone el cumplimiento de ciertos requisitos los cuales son determinados
en función de las necesidades del cliente En definitiva Calidad implica la determinación de las
actividades que se deben realizar el conocimiento de los requisitos a cumplir el adiestramiento
sobre esos requisitos, el cumplimiento estricto de los mismos, el compromiso y predisposición
positiva al trabajo y finalmente la vocación de servicio de todo el capital humano de una
organización. Por esta razón podemos afirmar que la conciencia de calidad dentro de la
organización es la base para la transformación de la organización en función de los requisitos
establecidos por el análisis de las necesidades y demandas del cliente, lo cual se logra
mediante el conocimiento (la visión compartida), el entendimiento del cliente y la mejora de
procesos.

11
1.4.2.- COMPROMISO TOTAL CON LA CALIDAD

La calidad de productos y servicios resulta de las contribuciones para la calidad de varios

individuos con muchas habilidades técnicas, de producción y administrativas diferentes. El
centro para el logro de la calidad es entonces, el compromiso positivo con la calidad que es
fundamental para los programas de control total de la calidad. Hay muchas formas en que
este compromiso evoluciona con la calidad y se logra, dependiendo sean la historia, políticas,
personalidades, recursos, etc, de la compañía. Lograr un compromiso genuino y generalizado
con la calidad es un proceso que tiene muchas dimensiones, y una es que nunca puede
considerarse "terminada". Una fuerza perecedera, sujeta a retos cambiantes continuamente,
demandas e influencias inesperadas de muchos lugares, el compromiso con la calidad se
puede considerar como un programa continuo que es básico para el control total de la calidad
y para los sistemas de calidad total.
Panorama del Compromiso con la Calidad
Lograr un compromiso generalizado hacia la calidad implica una gama muy amplia de
actividades continuas en todas las actividades del programa de calidad de la compañía. Está
basado en una política de calidad sólida, una planeación de la calidad cuidadosa y una
administración de la calidad "iluminada".
El control total de la calidad y los sistemas de calidad total implican, de esta forma, una amplia
gama de programas que hagan hincapié en el aseguramiento de una motivación positiva
hacia la calidad y un dinámico logro de la calidad por parte del personal de la compañía, en
cuando por lo menos, tres áreas fundamentales:
 La primera área es su actitud hacia la calidad.
 La segunda área es su conocimiento de la calidad.
 La tercera área son sus habilidades para calidad.
El alcance de esos programas puede incluir actividades de educación y entrenamiento para
la calidad, desde actividades planeadas para maximizar la exposición y experiencia en el
trabajo, hasta situaciones formalizadas de salón de clases, para la participación organizada
del empleado en la solución del problema de calidad.
Función de la Educación para la Calidad
Entre los aspectos fundamentales para el logro del compromiso con la calidad, está la
educación para la calidad. El objetivo administrativo básico puede ser formulado rápidamente.
Este objetivo se puede enunciar como:
"El desarrollo para el personal de la compañía – en todas las funciones y categoría – de
aquellas actitudes, conocimientos y habilidades en calidad que puedan aportar a los
productos de la compañía al costo mínimo congruentes con la satisfacción completa del
cliente".
Este objetivo no es nuevo. Mucho antes de que los programas de control total de la calidad
hubieran traído la atención generalizada, los gerentes de planta estaban tratando de dar
mayor importancia al entrenamiento para calidad de los nuevos operarios.
Los objetivos de la gerencia para la educación para calidad serán aquellos en que
los medios para lograrse puedan variar mucho en diferentes períodos. Para los problemas de
la calidad sólo se tiene una seguridad: su contenido está sujeto a cambios constantes. Por lo
tanto, la solución a los problemas de calidad será como un libro que está en proceso
de escritura, al cual se le agregaran constantemente más capítulos, pero sin que nunca se
llegue a escribir el último. La educación para la calidad nunca puede terminar en una
compañía vigorosa y dinámica, cuyos productos están en competencia efectiva en el actual

12
mercado cambiante en el mundo.
Conciencia para la Calidad
Históricamente, las actitudes para la calidad entre el personal de una planta, se han ido
adquiriendo, ya sea mediante un proceso educativo de la calidad que comprende no
únicamente los cursos formales de control de calidad, sino también en parte, muchas
influencias informales sobre la calidad.
Individualmente, el obrero de una planta es la base que se requiere para la elaboración de
productos de calidad satisfactoria. En la mayor parte de los casos, él es el que desea hacer
un trabajo satisfactorio: sin embargo, es muy importante rodearlo del "clima" apropiado para
que pueda realizarlo. Tiene que recurrir a sus supervisores y jefes para que lo ayuden en la
tarea indispensable de la calidad, para que le den una herramienta con la necesaria
capacidad, el entrenamiento conveniente para aplicar y mejorar su destreza y el equipo de
información de calidad para medir su rendimiento y guiarse en la operación del proceso del
cual tiene responsabilidad.
La conciencia para la calidad en el gerente general, debe ser más que un asunto de
palabrería. Las más contundentes arengas en favor de la calidad del producto, se esfuman
para los operarios cuando se recibe una orden en la fábrica para que se embarquen productos
subnormales en calidad, a fin de dar cumplimiento a la expedición de un pedido.
Los gerentes funcionales de la empresa confían en aplicar la política de la gerencia general
y al mismo tiempo obtener un trabajo funcional de acuerdo con el plan. Desgraciadamente,
no siempre se presentan las cosas de acuerdo con el plan y se inician los conflictos.
Una de las principales figuras en cualquier campaña sobre la conciencia para la calidad, es
el supervisor de una sección de producción. Éste representa dirección de primera línea, tanto
de nombre como de hecho, para todos los obreros que están bajo sus órdenes. Si está en
práctica un buen programa de relaciones laborales, el puesto del supervisor como parte
directiva está bien establecido, como también lo deben estar los conductos de información.
Por tanto, en una campaña de la conciencia para la calidad, el supervisor es el medio
de comunicación de la compañía. Más aún, la acción del supervisor en su línea, a favor de la
calidad del producto, debe respaldarse por los dirigentes intermedios y por la gerencia general
en todo caso. Si se procede de esta forma, el supervisor se sentirá seguro y será un defensor
de la causa de la calidad del producto.
Existe un gran número para interesar a los individuos y a los grupos, tendentes a promover
esa conciencia de la calidad. Estos medios se deben emplear durante determinados períodos.
Aun cuando sea una promoción pequeña, se pueden emplear con efectividad los siguientes
recursos:
 Notas cortas en el periódico de la planta
 Dibujos o caricaturas alusivas en el periódico
 Colocación de carteles en la zona de trabajo.
 Frases respecto a la calidad
 Sugerir recompensas por las ideas para mejorar la calidad
Para promover la conciencia de la calidad en toda la organización, es importante contar con
la participación de todo el personal. Si una persona no aprecia por completo el valor que para
él representa la elaboración de un producto con calidad, debe de tener presente su
importancia para todo el conjunto. Por lo tanto, cada persona debe pensar en que el bienestar
los incluye a ellos. Esto crea un espíritu de cuerpo en toda la organización.
Enfoque de Participación en el Compromiso con la Calidad: Círculos de Calidad, Calidad de

13
la Vida de Trabajo (CVT) y otros Enfoques Principales
Entre los enfoques principales para el compromiso de los grupos de empleados, se
comentarán tres aspectos en particular:
Círculos de Calidad.
Una de las formas más extendidas de participación de grupos de empleados es el círculo de
calidad. Un círculo de calidad es un grupo de empleados – normalmente de una sección de
la planta y de la actividad de la compañía – que se reúnen periódicamente para propósitos
prácticos como: señalar, examinar, analizar y resolver problemas, normalmente de calidad,
pero también de productividad, seguridad, relaciones laborales, costos, almacenes, etc.;
además, para realzar la comunicación entre empleados y administradores.
Una de las características exclusivas del círculo de la calidad, es el hincapié estructural en la
solución organizada de los puntos y problemas pertinentes de la planta y compañía. Uno de
los factores principales en la actividad del círculo de calidad es el entrenamiento de los
participantes del círculo en estas técnicas de análisis y síntesis.
Calidad de Vida de Trabajo (CVT)
Por muchos años, varias formas diferentes de programas han reunido a empleados con
supervisores y administradores de forma que todos puedan considerar métodos y medios
mejorados para manejar las mejoras de la calidad de vida de trabajo.
Una de las formas más amplias y recientemente conocidas del programa en sí ha sido descrita
como calidad de vida de trabajo y se basa sobre el principio de que la responsabilidad hacia
la calidad resulta más natural donde los trabajadores tienen intensa participación en las
decisiones que se reflejan en sus trabajos.
Las actividades de la CVT han tomado formas muy variadas en compañías diferentes; a los
trabajadores puede pedírseles que ayuden a diseñar sus propias líneas de ensamble o sus
estaciones de trabajo; los equipos de producción pueden encargarse de la elección y
entrenamiento de nuevos miembros del equipo sin una supervisión directa de la
administración; pueden asumir otras responsabilidades tradicionales de la administración,
tales como la predicción de los requisitos de materiales y mano de obra, y hasta pueden
evaluar su propio desempeño.
Otro Enfoques Importantes
El logro de la conciencia de la calidad y de la responsabilidad para la calidad dependen del
entusiasmo y cooperación generalizada, auténticas del empleado en toda la planta y
compañía en las actividades planeadas para el control total de la calidad.
Los enfoques participativos para impulsar la responsabilidad con la calidad en
muchas plantas y compañías han probado su valor durante los años. La clave para la
efectividad ha sido la elección de aquel programa de compromiso del empleado que satisfaga
en una forma genuina las necesidades y condiciones de la compañía específica. El
establecimiento por una compañía de un programa particular de mejoras en la calidad que
evoluciona a partir de sus requisitos e historia puede ser especialmente efectivo en muchos
casos.
Compromiso con la Calidad: Crecimiento Mundial del Campo de la Calidad
Ha habido una explosión literal en los últimos años en todos los continentes y en muchos
países de hombres y mujeres que practican el control de calidad en fábricas y oficinas en
algún área de calidad. Algunos son altamente profesionales en su práctica; muchos otros
están llegando a serlo muy rápidamente. La explosión de población de la comunidad mundial
de control de calidad puede resumirse en tres puntos centrales que son vitalmente
importantes pata todos los hombres y mujeres en el campo de la calidad:
 El primer punto es que la práctica del control de calidad no está ya concentrado en unos

14
pocos países y entre un número relativamente pequeño de hombres y mujeres
 Segundo, los desarrollos y progresos innovadores en el control de calidad están en
correspondencia amplia e importantemente basado a través de muchos países en el mundo
 Tercero, para practicar el control de calidad de forma consistente con la metodología mejor
y más moderna, se hace cada vez más importante mantenerse informados del progreso del
control de calidad y de las actividades en una base orientada mucho más internacionalmente
que nunca antes.
Al enfrentar el rápido crecimiento de la internacionalización, las perspectivas son que esto
profundizará y ampliará grandemente la contribución que los profesionales de la calidad
pueden hacer por el crecimiento y la salud del negocio de las compañías mientras éstas
enfrentan el mundo de hoy, cada vez más pequeño y competitivo.

15
1.4.3.- EL AUMENTO DEL RIESGO ASOCIADO A LA POCA CALIDAD

Debilidades

 Normalización inadecuada en cuanto a utilización y aplicación;

 Consumo de tiempo y costes;

 El riesgo de incrementar la burocracia;

 Problemas específicos con los centros relacionados con los tipos particulares de
centros educativos o formativos;

 El intenso papeleo necesario;

 Los altos costes de implantación de las normas;

 El tiempo requerido para llevar a término la implantación;

 Los altos costes de implantación de las normas;

 La falta de asesoramiento de la norma;

 La falta de coherencia entre los diversos auditores;

 El tiempo empleado en controlar la documentación antes de las auditorias;

16
1.5- CALIDAD TOTAL

Calidad total es una alusión a la mejora continua, con el objetivo de lograr la calidad óptima
en la totalidad de las áreas, es un concepto que explica como ofrecer el mayor grado de
satisfacción a un cliente por medio de un bien o servicio, para lograr la calidad total se debe
mejorar continuamente en la totalidad del bien o servicio, siguiendo con ello un bien o servicio
de calidad total, medido por la satisfacción total del cliente. La calidad total es un concepto,
una filosofía, una estrategia, un modelo de hacer negocios y está localizado hacia el cliente.
El concepto de calidad total distingue a 2 tipos de clientes, los cuales son identificados como
internos y externos. Se consideran clientes internos a los departamentos de la empresa que
solicitan un producto o servicio a otro departamento de la misma empresa. El cliente externo
es quien compra los productos o servicios a la empresa, sin necesariamente tener otra
relación con esta.

Por lo mismo la calidad total es un proceso el cual se suman esfuerzos para alcanzar una
meta establecida y superarla de forma relevante y mejorar el producto a servicio a ofertar.

El uso de la calidad total con lleva ventajas, pudiendo citar como ejemplos las siguientes:
 Potencialmente alcanzable si hay decisión del más alto nivel.
 Mejora la relación del curso humano con la dirección.
 Reduce los costos aumentando la productividad.

IMPORTANCIA DE LA CALIDAD TOTAL

La calidad total en la organización de una empresa, debe ser el nervio y motor de la misma;
si de verdad la empresa desea alcanzar el éxito debe cimentarse en estas dos palabras.

El mensaje de la calidad total debe ser comunicado a tres audiencias que son
complementarias entre sí:
 Los trabajadores
 Los proveedores; y,

 los clientes.

17
 UNIDAD 2
CALIDAD ENFOCADA AL
DESARROLLO DE SISTEMAS DE
INFORMACIÓN

18
2.1 CALIDAD EN LOS SISTEMAS DE INFORMACIÓN

¿Qué es calidad?
Conjunto de propiedades y características de un producto, proceso o servicio que
le hace satisfacer las necesidades establecidas o implícitas por el usuario.
¿Qué es un sistema de información?
Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las
actividades de una empresa o negocio.
La calidad en los sistemas de información;
Es la Concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos, los estándares de desarrollos explícitamente
documentado, y con las características implícitas que se espera de todo software
desarrollado profesionalmente.
(segun Pressman)
Todo producto o la implementación del mismo, se debe regir por normas o
estándares.
Un Estándar;
Busca mejorar la eficiencia y la calidad de un sistema, en este caso de
información, esto se hace a través de la implementación de un conjunto de reglas
al momento de desarrollar las diferentes etapas del sistema de información.
TIPOS DE ESTÁNDARES;
*Estándares de datos: Este estándar se refiere a cómo llamar las tablas, los
campos, los índices, las longitudes de las variables, esto es conocido como el
diccionario de datos en un sistema de información.
*Estándar de Codificación: Este estándar Son los que indican como llamar dentro
del código a la fuente, tipo, variables.
*Estándares de instructivo de Usuarios: Este estándar es el que indica mediante
un instructivo al usuario de cómo usar el sistema y cuál es la forma correcta de uso
para que el sistema no tenga inconvenientes.
*Estándares de instructivo de los operadores: Este estándar es un instructivo
funcional para los procesos específicos que van a orientar y ayudar a comprender
el flujo y el comportamiento de los procesos.
*Estándares estructurales: Este estándar se refiere a los lineamientos que deben
seguir para estructurar el software, dividir el software en módulos, codificación
estructural y la relación del sistema.

19
*Estándares de documentación: se refieren a características del diseño del
sistema u la relación de los componentes y las características de operación que
pueden realizarse para obtener detalles de la aplicación.
*Estándares de procesos: En este estándar se encuentran los siguientes
ambientes: Ambiente de desarrollo, Ambiente de prueba, Ambiente de producción,
Ambiente de centro de información y Ambiente de contingencia.
Un sistema de información de calidad, debe cumplir con normas y estándares de
calidad, que hace que sean confiables para los usuarios.

20
2.2 DEFECTOS Y ERRORES DE CALIDAD EN LOS SISTEMAS DE
INFORMACIÓN

Un defecto es la causa de un fallo. Es algo en el producto que:

*Está, pero no debe.
*No está, pero debe.
*No está como debe estar.
Un defecto es algo OBJETIVO que está equivocado en un programa:
*Error sintáctico, falta tipográfica, error de puntuación, ...
*Pueden estar en los programas, en los diseños o incluso en los requisitos.
*Los errores causan defectos, y todos provienen de errores humanos.
*Es decir, las personas cometen errores y los programas tienen defectos.
DEFECTOS;
Un defecto, es cualquier cosa que reduce la capacidad de los programas para
cumplir completa y efectivamente las necesidades de los usuarios. Un defecto es
algo que puedes identificar, describir y contabilizar.
ERRORES;
Son cosas incorrectas que cometen las personas y, sin tener en cuenta cuándo y
quién los comete, los errores son elementos defectuosos de los programas. Así las
personas cometen errores o equivocaciones mientras que los programas tienen
defectos.

21
22
2.2.1 EL CUADERNO DE REGISTRO DE DEFECTOS.

 El cuaderno de registro de defectos está diseñado para ayudarte a

reunir datos de defectos. El cuaderno se muestra en la siguiente figura:

 Y sus instrucciones se indican de esta manera:

 Utiliza este cuaderno para reunir datos de defectos para cada programa
que codifiques. Describe cada defecto con bastante detalle para que
puedas entenderlo más adelante. Después de haber terminado cada
programa, analiza los datos para ver dónde has introducido y eliminado
los defectos y qué tipos de defectos causan los principales problemas.

 PROPOSITO: utiliza esta tabla para mantener los datos de cada defecto
que encuentres y corrijas.

23
 METODO: anota todas las revisiones, compilaciones y prueba de
defectos en este cuaderno anota cada defecto de forma separada y
completa.

 CABECERA: introduce los siguientes datos nombre, fecha actual,

nombre del profesor y numero del programa.

 FECHA: la fecha en el que se encontró el defecto.

 NUMERO: numero de cada defecto.

 TIPO: anotar el tipo de defecto, utiliza tú criterio para determinar qué

tipo aplicar.

 INTRODUCIDO: la fase en la que surgió el defecto.

 ELIMINADO: anota la fecha en la que se elimino el defecto.

 TIEMPO DE CORRECION: estima o mide el tiempo que paso desde que

se encontró y fue corregido el defecto.

 DESCRIPCION: escribir una breve descripción del defecto corregido.

Haz la descripción lo suficientemente clara para recordar
posteriormente el error que causo el defecto.

24
2.2.2. CONTABILIZACIÓN DE DEFECTOS Y ERRORES.
 Durante la compilación, por ejemplo, cuenta solamente los cambios que
haces. Es decir, si el compilador presenta 10 mensajes de error por una
omisión del punto y coma, la omisión del punto y coma es un único defecto.
Así, anota un defecto en el Cuaderno de Registro de Defectos para cada
corrección del programa, sin tener en cuenta la naturaleza de la corrección y
el número de mensajes de error del compilador.

 Por ejemplo, si escribes una línea de código e inmediatamente ves un error en

el nombre del parámetro y lo corriges, este error no es un defecto.

 Si estás corrigiendo un error en los requisitos o en las especificaciones, eso

sería un defecto de requisitos o de especificación. Si, por el contrario, has
pensado una forma mejor de hacer el diseño, no sería un defecto. A menudo,
advertirás y corregirás errores conforme los vas cometiendo.

25
 Si, por el contrario, acabas de codificar el programa y posteriormente
observas el error, entonces sí sería un defecto y lo contabilizarías. Así, si
normalmente compruebas la corrección de cada línea después de introducirla,
los defectos que encuentres de esta forma no es necesario contabilizarlos.

 Comienza a contabilizar los defectos cuando termines una fase de un

producto o parte del mismo. Después de la fase de diseño, por ejemplo,
contarías todos los defectos de diseño. Supongamos, sin embargo, que estás
codificando dos procedimientos de un programa. Después de codificar el
primero, decides codificar el segundo, antes de comenzar la compilación del
primero.

 No se te exige contabilizar los defectos encontrados durante las fases de

diseño y codificación. Inicialmente, es importante concentrarte sobre aquellos
defectos encontrados durante la compilación y pruebas. Una vez que estés
acostumbrado a reunir datos de defectos, sabrás mejor por qué son
necesarios dichos datos.

26
2.2.3 FORMAS DE ENCONTRAR Y CORREGIR DEFECTOS

Defectos
Un defecto es algo OBJETIVO que está equivocado en un programa:
 Error sintáctico, falta tipográfica, error de puntuación, etc.

 Pueden estar en los programas, en los diseños o incluso en los requisitos.

 Los errores causan defectos, y todos provienen de errores humanos.

 Es decir, las personas cometen errores y los programas tienen defectos.

GESTION DE LOS DEFECTOS

 Registra cada defecto que encuentres en un programa.

 Registra la información suficiente sobre cada defecto para que puedas

entenderlo posteriormente.

 Analiza estos datos para ver qué tipos de defectos causan los mayores
problemas.

 Idea formas de encontrar y corregir estos defectos.

Formas de encontrar defectos:

• Con el compilador , pero no detecta los errores semánticos

• Las pruebas de unidad encuentra sobre el 50% de los defectos lógicos.

• Las de sistema entre un 30% y un 40%. Pero no podemos probar todos los
casos.

• La más común de todas: Que los detecten los usuarios.

Según Humphrey, la forma más rápida y eficiente es revisando personalmente el

código fuente.
o Así se ven los problemas, no los síntomas

o Sin embargo, con experiencia encontrará una media del 75% al 80% de los
defectos.

27
2.2.4 EL COSTO DE ENCONTRAR Y CORREGIR DEFECTOS

Costos de Prevención
Costo de todos aquellos esfuerzos para asegurar la calidad del software y prevenir
defectos en todas las fases del desarrollo de software.
• Aseguramiento de la calidad

• Requerimientos

• Administración del proyecto

• Librería de re-uso

• consultoría

Costos de evaluación
Costo del esfuerzo para descubrir la condición de la calidad del software
(evaluaciones planeadas).
• Evaluación del proyecto

• Auditorías de calidad del producto

• Evaluaciones externas

• Pruebas de productos adquiridos

Costos de fallas internas

Costo del esfuerzo para detectar y corregir problemas previos a que el usuario los
detecte.
• corregir defectos

• el trabajo correctivo en todas las etapas.

Costos de fallas externas

Costo del esfuerzo para corregir problemas que son detectados por el usuario.
• remoción de fallas

• soporte

• compensación

28
2.3 LISTAS DE COMPROBACIÓN.

Una lista de comprobación contiene una serie de pasos que tú quieres seguir de
forma rigurosa. Cuando utilizas una lista de comprobación desarrollada a partir de
tus propios defectos.
La lista de comprobación no solamente ayuda a encontrar más defectos, también
ayuda a encontrar más defectos de forma rápida.

Algunas orientaciones para utilizar la lista de comprobación son: haz las revisiones
paso a paso, completa cada programa o procedimiento antes de iniciar el siguiente.
Examina cada apartado de la lista de comprobación cuando lo completes.
Las listas de comprobación también pueden ser una fuente de ideas. Cuando sigues
una lista de comprobación personal. Sabes cómo revisar tu código.
Si utilizas correctamente, también sabes cuantos defectos encuentras en cada paso
de dicha lista, compara tu lista de comprobación con las de otros Ingenieros.
Ejemplo cotidiano de una lista de comprobación:

29
2.4 GESTIÓN DEL TIEMPO PARA EL DESARROLLO DE SISTEMAS DE
INFORMACIÓN.

Como Evaluar el Tiempo:

Ahora que sabes cómo usar tu tiempo. Decide que actividades son importantes y
considera si estas dedicándole el tiempo suficiente. Esta es la decisión importante
para equilibrar el trabajo.

Como encontrar más tiempo:

Después de haber revisado la estimación de tiempo, puedes necesitar aumentar la
cantidad de tiempo.
Como hacer esto:
Primero si tu agenda no está muy ocupada podrás encontrar un poco de tiempo
extra. Haz un estudio de todos tus compromisos.
Después revisa el tiempo que utilizaras tanto en las clases como en el área de
trabajo. Así como en las actividades de ocio.

Para gestionar bien tu tiempo analiza tus propios datos históricos. Establece una
estimación para utilizar el tiempo y registra tu tiempo real.

Las reglas Básicas para estimar el tiempo:

- Compromisos.
- Tareas.
-Rendimiento de tiempo Estimado.
Es importante saber administrar el poco o mucho tiempo que se tiene libre para
poder realizar cualquier proyecto y desarrollarlo de manera correcta.

En conclusión el poder gestionar tu tiempo para llevar a cabo un sistema va a

depender que tan completo, definido y estructurado este, así como la fluidez que
tendrás al dominarlo.

30
31
2.5 OBTENER CALIDAD DE LOS SISTEMAS DE INFORMACIÓN (MÉTODOS,
MÉTRICAS, METODOLOGÍAS Y ESTÁNDARES).
Para obtener una calidad de los sistemas de información se trata principalmente de:
Identificar: La empresa ha de averiguar cuáles son las necesidades de sus clientes.
Interiorizar: No basta con entender lo que los clientes desean. La empresa debe
aceptar esos deseos, necesidades y hacerlos suyos, ya que de otra forma no será
capaz de competir satisfactoriamente.
Satisfacer: una vez que la empresa ha aceptado las necesidades de sus clientes
debe realizar las mejoras necesarias en sus procesos para satisfacerlas.
Superar de forma continua: El objetivo de la empresa no es otro que cumplir con
las expectativas de sus clientes. Pero el proceso para conseguirlo es dinámico y
requiere la adaptación continua a los cambios en las necesidades y percepciones
de los clientes y a la presión de la competencia y sus nuevos productos y servicios.
Los principios de la gestión de la calidad moderna son [ISO 9001:2000]:
Organización enfocada al cliente: Las organizaciones dependen de sus clientes
y por tanto debían comprender las necesidades actuales y futuras de los clientes,
satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de
los clientes.
Liderazgo: Establecen la unidad de propósito y la orientación de la organización.
Crean y mantienen un ambiente interno.
Participación del personal: Es la escencia de la organización y su total
compromiso posibilita que sus habilidades sean usadas para el beneficio de la
organización.
Enfoque basado en procesos: Un resultado deseado se alcanza más
eficientemente cuando las actividades y los recursos relacionados se gestionan
como un proceso.
Enfoque de sistema para la gestión: Identificar, entender y gestionar los procesos
interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una
organización en el logro de sus objetivos.
Mejoramiento continúa: El desempeño global de la organización debería ser un
objetivo permanente de esta.
Enfoque basado en hechos para la toma de decisiones: Se basan en el análisis
de los datos y la información.
Relaciones mutuamente beneficiosas con los proveedores: Una organización y
sus proveedores son interdependientes, y una relación mutuamente beneficiosa
aumenta la capacidad de ambos para crear valor.

32
2.6 CONTROLAR LA CALIDAD DE LOS SISTEMAS DE INFORMACIÓN

En las áreas u organizaciones de TI la principal responsabilidad del aseguramiento

de calidad es determinar si las necesidades de los usuarios han sido satisfechas
adecuadamente.
El papel del control de calidad es comparar el producto contra otro producto cuyo
estándar y atributos han sido claramente definidos y son usados como referencia
de comparación.
El propósito del control de calidad es identificar defectos y corregirlos antes de
terminar el producto, realiza actividades tales como la revisión de sistemas y
pruebas de software. Se limita a revisar los productos y esta función puede ser
desempeñada por los desarrolladores mismos. Trabaja con productos.
El Aseguramiento de Calidad evalúa los sistemas antes de su instalación sin
discernir si se trata de nuevos desarrollos, nuevas funcionalidades o
mantenimientos, utiliza los resultados del Control de Calidad para evaluar y mejorar
los “procesos” que generan los productos, trabaja con procesos y esta función
evalúa tres elementos:

1. Objetivos: Las metas de la organización deben ser consideradas en primer

lugar dando pauta a los objetivos de los requerimientos del usuario. El grupo
de Aseguramiento de Calidad debe resaltar los conflictos entre ambos
objetivos, debe asegurarse de que los objetivos de unos y otros se
encuentren en armonía.

2. Métodos: Se ven manifiestos en las políticas, procedimientos, estándares y

guías la función del grupo debe evaluar su cumplimiento a lo largo del
desarrollo del trabajo.

3. Desempeño: Involucra un diseño calificado del sistema y el uso de las

técnicas de programación apropiadas.

33
2.7 COSTO DE LA CALIDAD EN LOS SISTEMAS DE INFORMACION
Costos de calidad aquellos costos necesarios para alcanzar la calidad, surgen por
la baja calidad existente o que pudiera existir.
Se puede considerar a los costos de mala calidad como las ineficiencias o
incumplimientos, los cuales son evitables, como por ejemplo: desperdicios,
devoluciones, reparaciones, reemplazos, gastos por atención de quejas y
exigencias de cumplimiento de garantías, entre otros.
Definir como costos de calidad, a la parte de los aspectos económicos de la calidad
que considera los gastos incurridos en la obtención y aseguramiento de una calidad
satisfactoria, así como las pérdidas originadas cuando no se obtiene ésta.
Joseph Juran clasifica los costos de calidad en cuatro categorías:
 Prevención.

 Evaluación.

 Falla interna.

 Falla Externa.

34
2.7.1 CÁLCULO DEL COSTO DE LA CALIDAD

Si llamamos P, E, Fi, Fe y C a las horas totales usados en el proyecto para

actividades categorizadas como Prevención, Evaluación, Fallas internas, Fallas
externas y Creación, respectivamente, tenemos que:
• Esfuerzo de Calidad = EoQ = (P+E+ Fi+Fe)

• Costo de Calidad = CoQ = (P+E+Fi+Fe) / (P+E+Fi+Fe+C)

• Esfuerzo de Mala Calidad = EoPQ = Fi+Fe

• Costo de Mala Calidad = CoPQ = (Fi+Fe) / (P+E+Fi+Fe+C)

Ejemplo.
En un proyecto se usaron 1280 horas de las cuales 280 horas se usaron en
administración, 60 en entrenamiento para el proyecto, 40 en adaptaciones del
proceso para el proyecto, 420 en creación, 50 en inspecciones, 160 en pruebas, 30
en correcciones debido a inspecciones, y 150 en corrección de errores antes de la
entrega, y 90 en correcciones finales después de la entrega. Quedan 1000 horas en
actividad del proyecto propiamente tal descontadas las horas de administración.

VARIABLES
PREVENCIÓN = P=60+40 = 100
EVALUACIÓN= E=50+160 = 210
FALLAS INTERNAS = Fi= 30+150 = 180
FALLAS EXTERNAS = Fe= 90
CREACIÓN = C = 420

EoQ = (P+E+ Fi+Fe) = 100 + 210 + 180 + 90 = 580

CoQ = (P+E+Fi+Fe) / (P+E+Fi+Fe+C) = (100 + 210 + 180 + 90) / (100 + 210 +
180 + 90 + 420) = 580 / 1000 = 58%
EoPQ = Fi + Fe = 180 + 90 = 270
CoPQ = (Fi+Fe) / (P+E+Fi+Fe+C) = (180 + 90) / (100 + 210 + 180 + 90 + 420) =
270 / 1000 = 27%

35
 UNIDAD 3

ASEGURAMIENTO DE LA CALIDAD
DE LOS SISTEMAS DE INFORMACIÓN
(SQA)

36
3.1 La función de aseguramiento de la calidad tiene como finalidad primaria el
determinar si las necesidades de los usuarios están siendo satisfechas
adecuadamente. Otra de sus funciones, aunque no se tocará mucho en la presente
investigación, es la de determinar los costos que puede causar el añadir ciertas
características al producto, ya que tarde o temprano, la economía resulta ser un
factor decisivo para obtener un producto de calidad. Para determinar si las
necesidades de los usuarios están siendo satisfechas, se deben de evaluar tres
áreas:

Objetivos: Los objetivos de la organización son primero, luego vienen los

requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en
armonía con los objetivos de la organización,

Métodos: Deben de utilizarse métodos que contengan u observen las políticas,

procedimientos y estándares de la organización,

Ejecución: Optimización del uso de hardware y software al implementar los

productos de software.

Para evaluar las áreas expuestas con anterioridad, es necesario que se cuente con
un programa de aseguramiento de calidad que sea efectivo y que tenga un impacto
dentro del desarrollo y prueba del producto de software final.

37
3.2 RELACIÓN DE LA INGENIERÍA DE SOFTWARE CON SQA.

La Ingeniería del Software es una disciplina o área de la informática o ciencias de

la computación, que ofrece métodos y técnicas para desarrollar y mantener software
de calidad que resuelven problemas de todo tipo.

Definiciones: Ingeniería

 Ingeniería del Software es el estudio de los principios y metodologías para

desarrollo y mantenimiento de sistemas de software. [Zelkovitz, 1978]
 Ingeniería del Software es la aplicación práctica del conocimiento científico
en el diseño y construcción de programas de computadora y la
documentación asociada requerida para desarrollar y operar (funcionar) y
mantenerlos. Así como también desarrollo de software o producción de
software. [Bohem, 1976]
 Ingeniería de Software es la aplicación de un enfoque sistemático,
disciplinado y cuantificable al desarrollo operación (funcionamiento) y
mantenimiento del software: es decir, la aplicación de ingeniería al software.
[IEEE, 1993]
 La Ingeniería de Software es una disciplina de la ingeniería que comprende
todos los aspectos de la producción de software desde las etapas iniciales
de la especificación del sistema hasta el mantenimiento de este después que
se utiliza. [Sommerville, 2004]

Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de
la computación, tales como construcción de compiladores, sistemas operativos, o
desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del
desarrollo de cualquier tipo de sistemas de información.
La creación del software es un proceso intrínsecamente creativo y la ingeniería del
software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso
en la consecución del objetivo creativo por medio de diversas técnicas que se han
demostrado adecuadas en base a la experiencia previa.

38
39
3.3 DEFINICIÓN Y PROPÓSITO SQA

Definición:
SQA es un set de actividades sistemáticas que aseguran que el proceso del
software y productos conformados por requerimientos, estándares, y
procedimientos. Los procesos incluyen todas las actividades involucradas en el
diseño, codificación, pruebas y mantenimiento; Los productos incluyen software,
datos asociados, documentación, y toda la documentación para soporte y reportes.
El rol para SQA es brindar a la administración la aseguranza de que procesos
oficialmente establecidos están siendo implementados. Y asegura que:
1.-Una metodología de desarrollo apropiada este establecida
2.-Que los proyectos utilicen estándares y procedimientos en su trabajo
3.-Que la documentación sea creada para mantenimiento y mejoramiento
4.-La administración de configuración de software este adecuada para controlar
cambios
5.-Se realicen pruebas y que se aprueben
6.-Cualquier deficiencia y desviaciones sean identificadas y llevadas con atención a
la administración.
Propósito:
Proporcionar visibilidad sobre los procesos utilizados por el proyecto de software y
sobre los productos que genera.
Objetivos:
1.-Planificar las actividades de aseguramiento de la calidad.
2.-Revisar y auditar objetivamente los productos y las actividades para verificar que
están conformes con los procedimientos y estándares aplicables.
3.-Proporcionar los resultados de estas revisiones o auditorías informando a la
dirección cuando sea necesaria su mediación.

La función de aseguramiento de la calidad tiene como finalidad primaria el

determinar si las necesidades de los usuarios están siendo satisfechas
adecuadamente. Otra de sus funciones, aunque no se tocará mucho en la presente
investigación, es la de determinar los costos que puede causar el añadir ciertas
características al producto, ya que tarde o temprano, la economía resulta ser un
factor decisivo para obtener un producto de calidad. Para determinar si las

40
necesidades de los usuarios están siendo satisfechas, se deben de evaluar tres
áreas:

Objetivos: Los objetivos de la organización son primero, luego vienen los

requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en
armonía con los objetivos de la organización,

Métodos: Deben de utilizarse métodos que contengan u observen las políticas,

procedimientos y estándares de la organización,

Ejecución: Optimización del uso de hardware y software al implementar los

productos de software.

Para evaluar las áreas expuestas con anterioridad, es necesario que se cuente con
un programa de aseguramiento de calidad que sea efectivo y que tenga un impacto
dentro del desarrollo y prueba del producto de software final.

41
3.4 Problemas Que Resuelve Sqa.

 Aumenta las posibilidades de el éxito final del proyecto

 Ayuda a definir los parámetros de medición de la calidad del software

 Verifica que los estándares sean aplicados correctamente

 Define un plan de monitoreo del proceso de desarrollo del software (ciclo de vida.

Obtener un SW de calidad.

La obtención de un software de calidad implica la utilización de metodologías o

procedimientos estándares para el análisis, diseño, programación y prueba del SW
que permitan uniformar la filosofía de trabajo.

La adopción de una buena política o metodología contribuye en gran medida a lograr

la calidad del SW pero no la asegura.
Esta política debe estar sustentada en 3 principios básicos.
1) Tecnológico: Define las técnicas a utilizar en el proceso de desarrollo de SW.
2) Administrativo: Contempla las funciones de planificación y control del desarrollo
de SW, así como la organización del ambiente o centro de ingeniería del SW.
3) Ergonómico: define la interfaz entre el usuario y el ambiente automatizado.
Para controlar la calidad del SW, es necesario definir los parámetros, indicadores o
criterios de medición.
Las cualidades para medir la calidad del SW se definen en 2 categorías:
- Complejidad de programa o código.
- Complejidad de sistema o estructura.

Por lo tanto, SQA resuelve problemas como:

Aumentar las posibilidades de éxito del proyecto.

Funcionalidad.
Cumplimiento.
Usable.

42
3.5 CICLO DE VIDA DEL SOFTWARE

El término ciclo de vida del software describe el desarrollo de software, desde la

fase inicial hasta la fase final. El propósito de este programa es definir las distintas
fases intermedias que se requieren para validar el desarrollo de la aplicación, es
decir, para garantizar que el software cumpla los requisitos para la aplicación y
verificación de los procedimientos de desarrollo: se asegura de que los métodos
utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores
que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite
que los errores se detecten lo antes posible y por lo tanto, permite a los
desarrolladores concentrarse en la calidad del software, en los plazos de
implementación y en los costos asociados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

• Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia

global.

• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los

requisitos del cliente y examinar cualquier restricción que se pueda aplicar.

• Diseño general: requisitos generales de la arquitectura de la aplicación.

• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.

• Programación (programación e implementación): es la implementación de un

lenguaje de programación para crear las funciones definidas durante la etapa de
diseño.

• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para

garantizar que se implementaron de acuerdo con las especificaciones.

• Integración: para garantizar que los diferentes módulos se integren con la

aplicación. Éste es el propósito de la prueba de integración que está
cuidadosamente documentada.

• Prueba beta (o validación), para garantizar que el software cumple con las
especificaciones originales.

• Documentación: sirve para documentar información necesaria para los usuarios

del software y para desarrollos futuros.

43
• Implementación

• Mantenimiento: para todos los procedimientos correctivos (mantenimiento

correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

Modelos de ciclo de vida

Para facilitar una metodología común entre el cliente y la compañía de software, los
modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo
involucradas y la documentación requerida, de manera que cada etapa se valide
antes de continuar con la siguiente etapa. Al final de cada etapa se arreglan las
revisiones de manera que (texto faltante).
Modelo en cascada: El modelo de ciclo de vida en cascada comenzó a diseñarse
en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases
en la que al final de cada una de ellas se reúne la documentación para garantizar
que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

Desarrollo en cascada
En Ingeniería de software el desarrollo en cascada, también llamado modelo en
cascada, es el enfoque metodológico que ordena rigurosamente las etapas

44
del proceso para el desarrollo de software, de tal forma que el inicio de cada
etapa debe esperar a la finalización de la etapa anterior. 1

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Implantación.
7. Mantenimiento.
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce
necesariamente al rediseño y nueva programación del código afectado,
aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la
metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un
cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la

industria[cita requerida], sigue siendo el paradigma más seguido al día de hoy.

Fases del modelo.

El "modelo cascada" sin modificar. El progreso fluye de arriba hacía abajo, como
una cascada.

45
Análisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software
para determinar qué objetivos debe cubrir. De esta fase surge una memoria
llamada SRD (documento de especificación de requisitos), que contiene la
especificación completa de lo que debe hacer el sistema sin entrar en detalles
internos.
Es importante señalar que en esta etapa se debe consensuar todo lo que
se requiere del sistema y será aquello lo que seguirá en las siguientes etapas,
no pudiéndose requerir nuevos resultados a mitad del proceso de
elaboración del software.
Diseño del Sistema
descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como
resultado surge el SDD (Documento de Diseño del Software), que contiene
la descripción de la estructura relacional global del sistema y la especificación
de lo que debe hacer cada una de sus partes, así como la manera en que se
combinan unas con otras.
Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño
detallado. El primero de ellos tiene como objetivo definir la estructura de la
solución (una vez que la fase de análisis ha descrito el problema)
identificando grandes módulos (conjuntos de funciones que van a estar
asociadas) y sus relaciones. Con ello se define la arquitectura de la solución
elegida. El segundo define los algoritmos empleados y la organización del
código para comenzar la implementación.
Diseño del Programa
Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario así como también los análisis
necesarios para saber que herramientas usar en la etapa de Codificación.
Codificación
Es la fase en donde se implementa el código fuente, haciendo uso de
prototipos así como de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las
bibliotecas y componentes reutilizables dentro del mismo proyecto para
hacer que la programación sea un proceso mucho más rápido.
Pruebas

46
 Los elementos, ya programados, se ensamblan para componer el sistema y
se comprueba que funciona correctamente y que cumple con los requisitos,
antes de ser entregado al usuario final.
Verificación
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el
sistema no falle.
Mantenimiento
Una de las etapas mas criticas, ya que se destina un 75% de los recursos,
es el mantenimiento del Software ya que al utilizarlo como usuario final puede
ser que no cumpla con todas nuestras expectativas.
Variantes

Existen variantes de este modelo; especialmente destacamos la que hace

uso de prototipos y en la que se establece un ciclo antes de llegar a la fase
de mantenimiento, verificando que el sistema final este libre de fallos.
Desventajas

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea
una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creación del software tarda mucho tiempo ya que debe pasar
por el proceso de prueba y hasta que el software no esté completo no se
opera. Esto es la base para que funcione bien.
Cualquier error de diseño detectado en la etapa de prueba conduce
necesariamente al rediseño y nueva programación del código afectado,
aumentando los costos del desarrollo.

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los
procedimientos utilizados para probar si la aplicación cumple las especificaciones
ya deben haberse creado en la fase de diseño.
Ciclos de Vida – Modelo en V
27 JULY 2010 NO COMMENT

47
Por Martha E Rojas Vera,

El modelo en V es una variación del modelo en cascada que muestra cómo se

relacionan las actividades de prueba con el análisis y el diseño. Como se muestra
en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a
la izquierda y las pruebas y el mantenimiento a la derecha.

Figura 3 Modelo de Ciclo de Vida en V

La unión mediante líneas discontinuas entre las fases de la parte izquierda y las
pruebas de la derecha representa una doble información. Por un lado sirve para
indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por
otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos
en las pruebas correspondientes.
Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones
de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo
en cascada se sitúa en los documentos y productos desarrollados, el modelo en V

48
se centra en las actividades y la corrección.
Ventajas y desventajas del Modelo en “V”

Ventajas:
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan
la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos

• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

49
3.6 Roles y responsabilidades de los equipos de desarrollo.

Rol._ es la función o papel que cumple alguien o algo.

La responsabilidad._ es asumir las consecuencias de todos aquellos actos que
realizamos en forma consciente e inconsciente.

¿Qué es un equipo?
―Al menos dos personas quienes están trabajando juntos por una
Meta/objetivo/misión común, donde a cada persona se le ha asignado roles
o funciones específicas a desarrollar, y en donde el cumplimiento de la misión
requiere algún tipo de dependencia entre los miembros del
grupo‖
Jean L. DyerEl desarrollo de software es una actividad que, dada su complejidad,
debe desarrollarse en grupo. Además, esta actividad requiere de distintas
capacidades, las que no se encuentran todas en una sola persona. Por ello, se hace
necesario formar el grupo de desarrollo con las personas que cubran todas las
capacidades requeridas
Cada una de esas personas aportará al grupo parte del total de las capacidades
necesarias para llevar a cabo con éxito el desarrollo. Por ello, es que cada persona
debe tener un rol dentro del grupo, que viene dado por su experiencia y capacidades
personales. En este capítulo se describen los roles que tradicionalmente se
consideran en el desarrollo de software. Estos roles son: Administrador de proyecto,
analista, diseñador, programador, téster, asegurador de calidad, documentador,
ingeniero de manutención, ingeniero de validación y verificación, administrador de
la configuración y por último, el cliente. Para cada uno de estos roles, se definen
sus objetivos, actividades, interacción con otros roles, herramientas a utilizar, perfil
de las personas en ese rol y un plan de trabajo. Hay que señalar que es posible que
no se requieran todos los roles en un desarrollo.

Eso dependerá del tamaño y del tipo del desarrollo. Por ejemplo, el desarrollo de un
sistema de información de gran tamaño requerirá más roles que uno de menor
tamaño. Por otro lado, si el tipo del proyecto está enfocado más hacia la
parametrización e integración de sistemas, requerirá algunos roles en menor
medida y otros en mayor.

Es posible también que una persona realice las labores de más de un rol al mismo
tiempo. Esto, sobre todo en proyectos de desarrollo de software más pequeños. No
obstante, es imprescindible que dichas personas conozcan completamente todas
sus tareas. Cada una de esas personas aportará al grupo parte del total de las
capacidades necesarias para llevar a cabo con éxito el desarrollo. Por ello, es que
cada persona debe tener un rol dentro del grupo, que viene dado por su experiencia
y capacidades personales. En este capítulo se describen los roles que
tradicionalmente se consideran en el desarrollo de software. Estos roles son:
Administrador de proyecto, analista, diseñador, programador, téster, asegurador de
calidad, documentador, ingeniero de manutención, ingeniero de validación y

50
verificación, administrador de la configuración y por último, el cliente. Para cada uno
de estos roles, se definen sus objetivos, actividades, interacción con otros roles,
herramientas a utilizar, perfil de las personas en ese rol y un plan de trabajo. Hay
que señalar que es posible que no se requieran todos los roles en un desarrollo.
Eso dependerá del tamaño y del tipo del desarrollo. Por ejemplo, el desarrollo de un
sistema de información de gran tamaño requerirá más roles que uno de menor
tamaño. Por otro lado, si el tipo del proyecto está enfocado más hacia la
parametrización e integración de sistemas, requerirá algunos roles en menor
medida y otros en mayor.

51
3.7 Habilidades y capacidades del personal del SQA

El asegurador de calidad debe ser una persona con mucha experiencia en proyectos
de desarrollo de software, con conocimientos suficientes sobre técnicas que
aseguren la calidad de un producto de software. Lo anterior lo hace capaz de
negociar con la calidad del producto, y ocasionalmente, modificar el criterio de
los desarrolladores. Considerando el Aseguramiento de la Calidad del software
como una de las claves áreas de proceso de CMM nivel 2, las habilidades para el
desempeño para el grupo de Aseguramiento de la calidad del Software son las
siguientes:

Habilidad 1:
Existe un grupo de Aseguramiento de Calidad que es el responsable de coordinar
e implementar las actividades de garantía de calidad para el proyecto. Un grupo se
considera como la colección de departamentos, gerentes e individuos que tienen
responsabilidades por un conjunto de tareas o actividades. Un grupo puede variar
desde una o varias personas asignadas a tiempo parcial de diferentes
departamentos, hasta varios individuos dedicados tiempo completo. Las
consideraciones a tener para implementar un grupo incluyen las tareas y actividades
asignadas, el tamaño de proyecto, la estructura y la cultura de la organización.
Algunos grupos, como el de aseguramiento de la calidad de software, están
enfocados a actividades de proyectos, y otros como el grupo de ingeniería de
procesos de software, están enfocados a actividades en el ámbito de toda la
organización

Habilidad 2:
Se provee de recursos y financiamiento adecuados para la realización de las
actividades de Aseguramiento de Calidad de Software.1.
Se asigna específicamente un gerente responsable por las actividades deSQA2.
Un gerente superior, quien es conocedor del SQA y tiene la autoridad de tomar
acciones de control, es designado para recibir y actuar sobre los ítems de software
no conformes.3.
Se dispone de herramientas de apoyo a SQA como son : estaciones de trabajo,
programas de bases de datos, programas de planilla de cálculo y herramientas de
auditoría.

Habilidad 3:
Los miembros del grupo de SQA están capacitados para realizarlas tareas
asociadas a esta actividad. Ejemplos de capacitación incluyen: Practicas y
habilidades de ingeniería de software, roles y responsabilidades del grupo de
ingeniería de software y otros grupos relacionados, métodos, estándares y
procedimientos para el proyecto de software, dominio de la aplicación del proyecto
de software, métodos, procedimientos y objetivos de garantía de calidad,

52
involucramiento del grupo SQA en las actividades del proyecto, un uso efectivo de
los métodos y herramientas de garantía de calidad, y comunicación interpersonal.

Habilidad 4:
Los miembros del proyecto reciben orientación en los roles, responsabilidades,
autoridad y valor del grupo de SQA.
Relación con otros roles:
A continuación se analiza la relación del asegurador de calidad con los otros roles:
• Administrador de proyecto: El asegurador de calidad revisa el plan de
Administración de proyecto, para asegurarse que se crea y que se sigue.
• Analista: El asegurador de calidad revisa la especificación.
n de requisitos de usuario y de software, para asegurarse que es una representación
correcta y completa de las expectativas del cliente, y que es suficientemente clara
para todos en el grupo de desarrollo, especialmente para el diseñador.
• Diseñador: El
Asegurador de calidad revisa la fase de diseño arquitectónico, para asegurarse que
el diseñador seleccionó la metodología apropiada y que el producto final de esta
fase cumple con requisitos de rendimiento, diseño y verificación.
• Programador: El asegura
dor de calidad revisa la fase de diseño detallado, para asegurarse que el código
producido cumple con la especificación de requisitos establecida y que cumple con
los atributos de calidad en uso.
•Téster: El asegurador de calidad revisa el plan de testeo, para asegurarse que es
creado, que es adecuado para el proyecto específico, y que se aplica encada fase
del proceso de desarrollo hasta la entrega del producto.
• Documentador: El asegurador de calidad revisa la documentación, para
asegurarse que corresponde con el software desarrollado, y que cumple con el
estándar en uso.
• Administrador de configuración: El asegurador de calidad revisa los registros
de cambios, errores y de configuración, para asegurarse de que los cambios han
sido implementados apropiadamente, y que las líneas bases son almacenadas
y que el producto no se puede perder.

53
3.8. Actividades del SQA

• Asesorarlos en sus funciones con respecto a la calidad (por ejemplo: cómo poner
bajo configuración sus documentos o programas, realizar respaldos, reportar sus
avances en las herramientas de planeación)
• Ser guía y mentor en las revisiones entre colegas (asistiendo con ellos las primeras
veces que éstas se ejecuten).
• Ayudarles a visualizar las metas cortas y a su nivel, tal como registrar los tiempos
de corrección de defectos, registrar el tiempo real de ejecución de las tareas
asignadas.
• Mostrarles cómo los procesos les ayudan a hacer mejor su trabajo.

Asesorarlos en aspectos relacionados con su proyecto (ayudarlos en la manera

de cómo aplicar algún proceso a su proyecto, asesorarlos en el llenado de formatos
nuevos o bien en el registro o información requerida, registro de estimaciones,
lecciones aprendidas).
Recompensar sus esfuerzos, dándoles visibilidad. Esto es, comentar con los
niveles superiores, cuando sea posible, cuales son los puntos en los cuales se han
destacado.
Señalar las desviaciones, pero aplaudir los logros. Registrar los logros en los
reportes de revisión-
Entrenan para mejorar la calidad. Los responsables del proyecto, requieren que se
les ayude a visualizar de manera sencilla, cuáles son los aspectos que deben
cuidar en su trabajo diario para mejorar la calidad de sus proyectos.
Escuchar y escalar sus sugerencias de mejora. Es muy importante este punto,
pues con ello, las responsables del proyecto realmente se sentirán parte del proceso
de mejora continua.
Mostrándoles como los procesos les ayudan a hacer mejor su trabajo. Hacerles
ver la manera práctica los beneficios que se obtienen al seguir los procesos

2.8 Metodos y Herramientas del SQA.

Método:
Su significado original señala el camino que conduce a un lugar.
Herramienta:
Una herramienta es un objeto elaborado a fin de facilitarla realización de una tarea
mecánica que requiere de una aplicación correcta de energía.

METODOS DEL SQA:

Los métodos más comunes para el aseguramiento de la calidad son los
siguientes:
1) Auditorías PPQA (Process and Product Quality Assurance):
Esla actividad de garantizar que el proceso y el producto de trabajos Se ajustan al
plan acordado.
2) Pruebas de Validación:

54
Es el acto de introducir datos, los cuales el tester sabe que son erróneos en la
aplicación.
3) Comparación de datos:
Técnica que se realiza comparando los resultados de una aplicación con parámetros
específicos con los resultados de otra aplicación previamente creada,
introduciéndolos mismos parámetros de manera que se obtenga un resultado
exacto.
4) Prueba de esfuerzo (Stress Testing)
Se realiza cuando el SW es utilizado de la manera más ruda posible en un
período de tiempo para ver si trabaja con altos niveles de carga
5) Pruebas de Uso:
A veces conseguir usuarios que no estén familiarizados con el SW para probarlo
por entiempo determinado, ofrece retroalimentación a los desarrolladores acerca de
las dificultades que encontraron. Esta es la mejor maneta de realizar mejoras a la
interfaz.
6) Revisiones por Pares (Peer Reviews).
Son actividades efectivas para el control de la calidad. Pueden aplicarse al análisis,
diseño y codificación.
7) Revisión Técnica formal (RTF):
Es una actividad de garantía de calidad de SW. Es una revisión que incluye
recorridos, inspecciones y revisiones cíclicas.

HERRAMIENTAS DEL SQA:

Las herramientas utilizadas en SQA son generalmente las herramientas de prueba
en donde una aplicación se ejecuta a través de una serie de pruebas para medir el
rendimiento de la aplicación.

Estas herramientas se emplean para probar la aplicación y producir números y

estadísticas sobre la aplicación real. A través de estos números, el equipo de SQA
y sus desarrolladores se sabe si la solicitud ha cumplido de acuerdo a los resultados
específicos.

WinRunner:
Desarrollado por HP, WinRunner es un amistoso aplicación de usuario que puede
probar la reacción de las aplicaciones del usuario. Pero aparte de medir el tiempo
de respuesta, WinRunner también puede reproducir y verificar todas las
transacciones y la interacción de la aplicación tenido con el usuario. La aplicación
funciona como un simple usuario y capta y registra todas las respuestas que hace
la aplicación.

LoadRunner:
Desarrollado por HP LoadRunner es una delas aplicaciones simples que puede
probar el rendimiento real de la aplicación. Tiene la capacidad de trabajar al igual
que miles de usuarios al mismo tiempo.

QuickTest Profesional:

55
Creado por HP, QuickTest emula las acciones de los usuarios y explota la aplicación
según el procedimiento establecido por los probadores. Puede ser utilizado en la
GUI y la no
GUI sitios web y aplicaciones. La herramienta de prueba puede ser personalizado
a través de diferentes plugins

Mercurio TestDirector:
Un todo-en-un paquete, este interfaz basada en web, podría ser utilizado de
principio afín en la prueba de una aplicación o un sitio web. Todos los defectos serán
gestionados de acuerdo a su efecto a la aplicación. Los usuarios también tendrán
la opción de utilizar esta exclusivamente para su aplicación o uso que junto con la
amplia gama de probadores

SilkTest:
Aunque está disponible en el sistema operativo limitado, SilkTest es una
herramienta de prueba muy inteligente. SilkTest listas de todas las funciones
posibles y trata de identificar la función de uno. Puede ser aplicado en pequeñas
iteraciones, ya que traducir los códigos disponibles en objetos reales.
Bugzilla:
Desarrollado por Mozilla, esta herramienta de código abierto de prueba funciona
como su nombre indica. Bugzilla se especializa en la detección de errores
encontrados en la aplicación o página web.

Application Center Test:

También conocido como AcT,esta herramienta de prueba fue desarrollada por
Microsoft con [Link]. Esta aplicación se utiliza principalmente para determinar la
capacidad de los servidores que se encargan de la aplicación. Probadores puede
probar el servidor haciendo constantes solicitudes. Una secuencia de comandos
personalizados ya sea desde VB o JS se podría utilizar para poner aprueba la
capacidad del servidor.

OpenSTA:
Otra herramienta de código abierto, los probadores pueden iniciar la aplicación y el
uso que delas pruebas de aplicaciones de estrés de la capacidad. El proceso de
prueba puede ser registrado y los tiempos de las pruebas podrían ser programadas.
Ideal para sitios web que necesita mantenimiento diario.

Qarun:
En lugar de una aplicación, Coré es en realidad una plataforma en la que puede
generar la aplicación de pruebas propias. Qarun puede ser fácilmente integrada con
la aplicación de modo que fácilmente podía sincronizar con las emisiones y los
controles de la aplicación o página web cada vez que algo nuevo se introduce

56
3.6.1-Roles y responsabilidades del equipo de desarrollo.

Roles del equipo de trabajo

1. Comité Directivo. El Comité Directivo estará conformado por el equipo gerencial

de Monsanto Cancar. El comité tendrá la misión de asegurar la correcta ejecución
del proyecto, revisando los puntos de certificación o hitos y elementos claves del
proyecto. Deberá asegurarse que se cumplan los hitos y tomar las medidas de
ajuste necesarias para garantizar el cumplimiento satisfactorio del proyecto.
Proporciona los recursos financieros, humanos y físicos que requiera el proyecto.

2. Director del Proyecto MONSANTO CANCAR. Es un funcionario de alto nivel

encargado de consolidar los intereses estratégicos de Monsanto y velar porque
estos estén adecuadamente atendidos por el proyecto. Asesora y/o preside el
Comité Directivo.

3. Director del Proyecto CRPQ. Es un funcionario de CRPQ encargado de orientar

el documento que contiene la Visión/Alcance del proyecto y asesorar al Comité
Directivo para asegurar que las expectativas de sean cabalmente satisfechas.

4. Gerente del Proyecto MONSANTO CANCAR. Es un funcionario de MONSANTO

CANCAR, encargado de administrar las relaciones y coordinación entre los equipos
de trabajo de CRPQ y MONSANTO CANCAR. Trabajará en coordinación estrecha
con su par de CRPQ y se reunirá con este para asegurar la apropiación de recursos
físicos y humanos. Administra las comunicaciones escritas con los clientes, coordina
la realización de reuniones de trabajo de acuerdo con el cronograma y la
disponibilidad de los integrantes, y en general, representa a Monsanto en todos los
aspectos relacionados con el proyecto, tanto hacia el interior de la compañía como
hacia el exterior.

5. Gerente del Proyecto CRPQ. Es un funcionario de CRPQ encargado de coordinar

la ejecución del proyecto. Se reúne con el Gerente del Proyecto por parte de
Monsanto para coordinar la apropiación de recursos físicos y humanos. Prepara los
planes administrativos del proyecto y participa como facilitador metodológico en las
reuniones de trabajo de los grupos de profesionales que trabajen en el proyecto.

6. Líderes funcionales. Son profesionales de cada área, expertos en los procesos

de las diferentes unidades organizacionales y/o de negocio estratégico. Su

57
participación es esporádica, de acuerdo con la programación que asigne el
Champion, con base en el cronograma de trabajo.

7. Líderes metodológicos. Son profesionales asignados a cada grupo estratégico

para coordinar las labores metodológicas y administrativas relacionadas con el
desarrollo del proyecto.

8. Champion de cada unidad estratégica. El equipo gerencial designa un gerente de

área para responder por el desarrollo de la implementación de los contenidos de
cada una de las directrices estratégicas del plan estratégico. Su rol consiste en
liderar al grupo de trabajo en la definición, ejecución y seguimiento de los proyectos
necesarios para materializar las directrices estratégicas.

Rol

Responsabilidades

Tiempo asignado al proyecto

Director de proyecto CRPQ

1. Propone el diseño general del enfoque, criterios, principios, estructura y

metodología del proyecto.

2. Dirige la preparación de los planes del proyecto

3. Asesora al Comité Directivo, participa como miembro en sus reuniones y presenta

a este cuerpo los informes de avance del proyecto y ajustes al cronograma de
actividades

4. Negocia los acuerdos formales

5. Efectua reuniones periódicas de seguimiento con el gerente de proyecto

6. Ayuda en la resolución de conflictos y asuntos escalados.

7. Dirigi talleres de entrenamiento e inducción de directivos y ejecutivos.

Parcial 3/4

58
Director de proyecto MONSANTO CANCAR

1. Representante de alto nivel del Comité Directivo, “patrocinador” del proyecto.

2. Resuelve conflictos y problemas escalados por el gerente del proyecto o

cualquiera de sus integrantes

3. Interviene en la preparación de los planes del proyecto

4. Negocia los acuerdos formales

5. Efectúa reuniones periódicas de seguimiento con el gerente de proyecto interno

6. Efectúa reuniones periódicas de seguimiento con su par de la consultoría

Parcial 3/4

Gerente de proyecto CRPQ

1. Prepara el plan detallado administrativo del proyecto con el cronograma de

actividades

2. Acuerda con el Gerente del Proyecto de Monsanto las actividades asociadas con
la logística, comunicaciones, reuinones con grupos de trabajo y preparación de los
informes de avance.

3. Hace seguimiento a la ejecución y comunica a su gerente par y al director del

proyecto cualquier modificación en los planes y cronogramas.

4. Reprograma el proyecto si se presentan atrasos para reencaminar y asegurar su

cumplimiento.

5. Asegura que los entregables del proyecto sean aprobados por las instancias
adecuadas.

6. Asegura la ejecución del programa con los requerimientos de calidad definidos,

dentro del plazo acordado y al costo contratado.

7. Administra los cambios mediante acuerdos formales presentdos al Comité

Directivo

59
8. Resuelve conflictos o los escala al director CRPQ

Completo

Gerente de proyecto MONSANTO CANCAR

1. Coordina las fechas de reuniones de los grupos de trabajo

2. Administra las relaciones de trabajo entre los grupos de trabajo internos y los
consultores

3. Asegura la disponibilidad de recursos logísticos y de comunicaciones necesarios

para el desarrollo del proyecto.

4. Se asegura que las unidades organizacionales participan en el proyecto en el

momento indicado.

5. Representa los intereses de Monsanto en el equipo del proyecto y asegura que

las expectativas explícitas de los usuarios sean atendidas y articuladas por el equipo
de trabajo, tanto interno como de la consultoria.

6. Supervisa el contrato celebrado con el consultor

7. Recibe y aprueba, junto con los funcionarios apropiados, cada uno de los
entregables del proyecto y da el visto bueno para continuar a las siguientes fases
hasta su terminación.

8. Asegura que los entregables de cada módulo satisfacen los requerimientos de

calidad y aceptación definidos por MONSANTO CANCAR y plasmados en el
contrato.

9. Participa en las reuniones del Comité Directivo.

10. Asegura que los la ejecución de los planes y procedimientos se siguen de

acuerdo con lo establecido por escrito.

11. Escala asuntos y problemas hacia el equipo directivo a través del director
Monsanto cuando se requiera.

60
12. Asegura que se aprueben las propuestas de solución a los problemas que
pudieran surgir.

Parcial 3/4

Líderes temáticos

Confluyen a las reuniones de trabajo para aportar sus conocimientos profesionales

específicos. Describen los flujos de información y documentos que requieren los
procesos del negocio.

Parcial

Líderes metodológicos

1. Profesionales de Monsanto asignados a cada grupo de trabajo o SBU

2. Coordinan las reuniones de trabajo de su SBU, según la programación del

cronograma

Champion de cada SBU

1. Lideran el desarrollo de los contenidos del trabajo del SBU correspondiente

2. Definen y asignan responsabilidades de su grupo de trabajo en el SBU

3. Coordinan y definen la disponibilidad de tiempo y fechas para la realización de

reuniones de trabajo (las cuales incluyen en los cronogramas los gerentes del
proyecto – (Monsanto y consultoría)

4. Aseguran la asignación de recursos para el desarrollo del trabajo.

5. Revisan y aprueban los documentos elaborados por su grupo de trabajo

6. Asisten a las reuniones de trabajo, según la necesidad y tema a tratarse

7. Responden por la calidad de los contenidos

61
Puesto Responsabilidad
El jefe de proyecto asigna los recursos, gestiona
las prioridades, coordina las interacciones con
los clientes y usuarios, y mantiene al equipo del
proyecto enfocado en los objetivos. El jefe de
proyecto también establece un conjunto de
Jefe de
prácticas que aseguran la integridad y calidad de
Proyecto
los artefactos del proyecto. Además, el jefe de
proyecto se encargará de supervisar el
establecimiento de la arquitectura del sistema.
Gestión de riesgos. Planificación y control del
proyecto.
Captura, especificación y validación de
requisitos, interactuando con el cliente y los
Analista de usuarios mediante entrevistas. Elaboración del
Sistemas Modelo de Análisis y Diseño. Colaboración en la
elaboración de las pruebas funcionales y el
modelo de datos.
Construcción de prototipos. Colaboración en la
Programador elaboración de las pruebas funcionales, modelo
de datos y en las validaciones con el usuario
Gestión de requisitos, gestión de configuración y
cambios, elaboración del modelo de datos,
Ingeniero de
preparación de las pruebas funcionales,
Software
elaboración de la documentación. Elaborar
modelos de implementación y despliegue.

62
3.7.1- Habilidades y capacidades del personal de SQA

Habilidad
Existen diferentes definiciones que intentan englobar el concepto de habilidad:
Es el grado de competencia de un sujeto concreto frente a un objetivo
determinado. Es decir, en el momento en el que se alcanza el objetivo propuesto en
la habilidad.
Se considera como a una aptitud innata o desarrollada o varias de estas, y al
grado de mejora que se consiga a esta/s mediante la práctica, se le denomina
talento.
Es la destreza para ejecutar una cosa o capacidad y disposición para negociar y
conseguir los objetivos a través de unos hechos en relación con las personas, bien
a título individual o bien en grupo.

Capacidad
La capacidad se refiere a los recursos y aptitudes que tiene un individuo, entidad o
institución para desempeñar una determinada tarea o cometido.
EL EQUIPO O GRUPO DE SQA

El equipo de SQA trabaja con la gerencia de proyectos durante los inicios del
desarrollo para establecer los planes, estándares y los procedimientos que
agregarán valor al proyecto de SW y satisfacer los problemas del proyecto y de las
políticas de la organización.
Participa en establecer los planes, estándares y procedimientos.
El equipo ayuda a asegurar que se cumplan con las necesidades del proyecto y
verifica que sean usables para realizar revisiones e intervenciones durante todo el
ciclo de vida.
Las revisiones del grupo de SQA proyectan las actividades y revisan el producto de
trabajo de SW, además de proveer a la gerencia la posibilidad de saber si el
proyecto está de acuerdo a los planes estándares y procedimientos establecidos
EL GRUPO ENCARGADO DE SQA.
- Trabaja con el equipo del proyecto desde el inicio.
- Debe ser objetivo e independiente.
- Ayuda al proyecto, más que controlar sus actividades.

63
La actividad de SQA es el proceso de verificación de que los estándares sean
aplicados correctamente. En los proyectos pequeños esto se puede realizar por el
equipo de desarrollo, pero en proyectos grandes, un grupo específico se debe
dedicar a este rol.

“Como policía del proceso”: el trabajo del equipo de SQA es asegurar que el
desarrollo
Sigue el proceso establecido. Entre sus funciones en este rol se encuentran:
* Auditar los productos del trabajo para identificar deficiencias.
* Determinar el cumplimiento del plan de desarrollo del proyecto y del
Proceso de desarrollo de software.
* Juzgar el proceso y no el producto.

“Como abogado del cliente”: el trabajo del equipo de SQA es representar al cliente.
Entre sus funciones en este rol se encuentran:
* Identificar la funcionalidad que al cliente le gustaría encontrar.
* Ayudar a la organización a sensibilizarse con las necesidades del cliente.
* Actuar como un cliente de prueba para obtener una alta satisfacción del
Cliente.
“Como analista” el trabajo del equipo de SQA es recabar información. Entre sus
Funciones en este rol se encuentran:
* Juntar muchos datos sobre todos los aspectos del producto y del proceso.
*Con esta información ayudar a mejorar los procesos y los productos.
“Como proveedor de información” el trabajo del equipo de SQA es revisar qué es lo
que
Este hecho y decir cuáles objetivos técnicos realmente están cumplidos para que la
Gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en este
rol se
Encuentran:
* Proveer información técnica objetiva para que la gerencia pueda usarla

64
Para tomar mejores decisiones.
* Proveer información apropiada de las clases de productos y de los
Riesgos asociados con estos.
*Concentrarse más en la reducción de los riesgos que en el cumplimiento
Del proceso.
“Como responsable de la elaboración del proceso” el trabajo del equipo de SQA es
Participar en la definición de los planes, procesos, estándares y procedimientos para
Asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados
para
Realizar las evaluaciones de QA y cumplir los requerimientos del proyecto y las
políticas
De la organización. Para cumplir este rol el aseguramiento de la calidad debería
Comenzar en las fases tempranas del proyecto.
Aquí conviene aclarar que no necesariamente las personas que definen la
metodología a
Seguir pertenece al equipo de QA. Definir la metodología puede llegar a ser o no
una
Actividad del equipo de QA. Una estructura posible en el proceso de mejora del
Software puede contar con un SEPG (Software Engineering Process Group)
Totalmente independiente del equipo de QA, encargado de definir la metodología
Mientras que el equipo de QA se limita a verificar que se cumpla dicha metodología.

65
 UNIDAD 4
NOMENCLATURA Y CERTIFICACION
DE ISO 9001:2000

66
4.1 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 2000 ISO9001:2000, 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.
Los ocho principios de la gestión de la calidad identificados para lograr los objetivos
de la calidad, según "ISO 9000:2000 Sistemas de Gestión de la Calidad.
Fundamentos y vocabulario." son:
1. Enfoque al cliente. Las organizaciones dependen de sus clientes y por la tanto
deberían comprender las necesidades actuales y futuras de los clientes,
satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas
de los clientes.
2. Liderazgo. Los líderes establecen la unidad de propósito y la orientación de la
organización. Ellos deberían crear y mantener un ambiente interno, en el cual
el personal pueda llegar a involucrarse totalmente en el logro de los objetivos
de la organización.
3. Participación del personal. El personal, a todos los niveles, es la esencia de
una organización y su total compromiso posibilita que sus habilidades sean
usadas para el beneficio de la organización.
4. Enfoque basado en procesos. Un resultado deseado se alcanza más
eficientemente cuando las actividades y los recursos relacionados se gestionan
como un proceso.
5. Enfoque de sistema hacia la gestión. Identificar, entender y gestionar los
procesos interrelacionados como un sistema, contribuye a la eficacia y
eficiencia de una organización en el logro de sus objetivos.
6. Mejora continua. La mejora continua del desempeñoglobal de la organización
debería ser un objetivo permanente de ésta.
7. Enfoque basado en hechos para la toma de decisiones. Las decisiones
eficaces se basan en el análisis de los datos y la información.
8. Relación mutuamente beneficiosa con el proveedor . Una organización y
sus proveedores son interdependientes, y una relación mutuamente
beneficiosa aumenta la capacidad de ambos para crear valor.

67
Estos ocho principios de gestión de la calidad constituyen la base de las normas
de sistemas de gestión de la calidad de la familia de Normas ISO 9000.
Para entender bien la relación de estos aspectos, es preferible observar la
siguiente gráfica:

68
 4.2 LA NORMA ISO/IEC 9126

La Organización Internacional para la Estandarización (ISO) dispone de dos definiciones de

usabilidad:

ISO /ICE 9126

“La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y

ser atractivo para el usuario, en condiciones específicas de uso”

Esta definición hace énfasis en los atributos internos y externos del producto, los cuales
contribuyen a su usabilidad, funcionalidad y eficiencia.

La usabilidad depende no sólo del producto sino también del usuario. Por ello un producto no es
en ningún caso intrínsecamente usable, sólo tendrá la capacidad de ser usado en un contexto
particular y por usuarios particulares. La usabilidad no puede ser valorada estudiando un
producto de manera aislada (Bevan, 1994).

La norma ISO/IEC 9126 está enfocada a la calidad de Producto y consta de las siguientes
partes:

Parte 1: Modelo de Calidad

Parte 2: Métricas externas

Parte 3: Métricas internas

Parte 4: Calidad en el uso de métricas

La especificación y la evaluación de la calidad de producto de software se puede conseguir

definiendo características de calidad apropiadas, tomando en cuenta el objetivo de uso del
producto de software.

Las métricas utilizadas las presentaremos integradas según la norma ISO/IEC 9126–1 (Modelo
de Calidad) y su evaluación la realizaremos aplicando la norma ISO 14598.

El modelo estructura los atributos de calidad de software en seis características (funcionalidad,

fiabilidad, utilidad, eficacia, capacidad de mantenimiento y portabilidad), que se subdivididen en
subcaracterísticas. Las subcaracterísticas pueden ser medidas por métricas internas o externas.

69
CAPACIDAD DE ANÁLISIS

Deberían ser capaces de medir atributos tales como los recursos o esfuerzo de mantenimiento
o del usuario en el diagnóstico de incidencias o causas de fallo del software, o identificar las
partes a ser modificadas.

Las métricas presentadas en ISO/IEC TR 9126–2, son:

· Soporte a la función de diagnosis

· Datos registrados durante la operación.

· Tiempo de análisis del fallo

· Éxitos al encontrar causas de fallo

· Monitorización del estado durante la operación

3. CAPACIDAD DE CAMBIO

Deberían ser capaces de medir atributos tales como el esfuerzo del personal de mantenimiento
o del usuario midiendo el comportamiento del personal de mantenimiento, usuario o sistemas,
incluyendo el software cuando tratan de implementar una modificación especificada.

· Registrabilidad de cambios.

· Facilidad de parametrización.

· Disposición para el cambio.

Tiempo empleado en implementar el cambio para satisfacción del usuario.

· Tiempo empleado en implementar un cambio por el personal de mantenimiento.

4. PROCEDIMIENTO/CRITERIOS ADAPTACIÓN DEL MODELO

La base sobre la cual las métricas son seleccionadas depende de los objetivos de negocio
especificados para el producto y las necesidades del evaluador. Para ello utilizamos la norma
ISO 14598 y la norma ISO 9126, especificando el criterio de adaptación al modelo de calidad y
las métricas seleccionadas, que serán evaluadas.

70
El procedimiento seguido para la obtención de un valor que integre las subcaracterísticas
“Capacidad de Análisis” y “Capacidad de Cambio”, se fundamenta en la visión de usuarios,
desarrolladores y gestores, sobre las métricas de calidad de software a aplicar. Para ello se han
aplicado las siguientes estrategias, métodos, procedimientos y plantillas:

· Checklist informada por usuarios, desarrolladores y gestores, expresando su valoración/peso

de los factores de calidad. Los resultados se consolidan a nivel global indicando el peso de cada
uno de los parámetros en el valor final.

· Propuesta de varias métricas por cada una de las subcaracterísticas y agregación a nivel global
para obtener un valor conjunto de la característica “Capacidad de Mantenimiento”, cubriendo las
subcaracterísticas “Capacidad de Análisis” y “Capacidad de Cambio”.

· Entorno de trabajo. Las métricas consideradas cubren el esfuerzo del personal de

mantenimiento, en la realización de los siguientes tipos de actividades:

· Mantenimiento Correctivo, resolución de Incidencias.

· Mantenimiento Adaptativo, desarrollo e implantación de Mejoras y Cambios.

· Aplicación de plantillas estándar a las métricas seleccionadas, para su definición, asignación

de valores límite y su desglose en categorías.

· La utilización de las plantillas sobre los datos registrados, permite obtener: Valores límite de
cada una de las métricas, criterios de evaluación por categoría y su agregación para obtener una
valoración a nivel de subcaracterística y característica.

· Las métricas de niveles de agregación superiores se calculan a partir de los valores de métricas
del nivel de agregación inferior. El nivel de agregación superior está formado por los factores de
calidad, definidos, que constituyen las características y subcaracterísticas seleccionadas de la
norma ISO/IEC 9126.

Las métricas se validan de forma empírica mediante una relación causa-efecto y mediante la
extracción de conclusiones.

Las métricas primitivas utilizadas, son:

5. MÉTRICAS SELECCIONADAS

6. RESULTADOS OBTENIDOS

71
Los datos han sido obtenidos de 126 aplicaciones, que se encuentran actualmente en
explotación. No se ha realizado una segmentación de las aplicaciones por tipo de tecnología o
arquitectura,

CONCLUSIONES

A continuación se presentan una serie de conclusiones generales sobre la aplicación de métricas

para las subcaracterísticas “Capacidad de Análisis” y “Capacidad de Cambio”, utilizando la norma
ISO 9126.

La aplicación del modelo obliga a disponer de

· Una normativa metodológica de gestión de las actividades de mantenimiento y desarrollo.

· Herramienta de gestión integradas en la metodología.

· Definición de responsabilidades en la ejecución de actividades.

· Necesidad de informar correctamente en las herramientas.

· Mecanismos de comunicación entre diferentes tipos de usuaros.

La aplicación del modelo ha planteado los siguientes problemas:

· Asignación a las incidencias de su origen.

· Recogida de información asociada a pruebas.

· Filtrado de información por tipo de tecnología.

· La asignación de intervalos de referencia para realizar una evaluación, puede exigir un análisis
riguroso en función de uno o varios parámetros.

La aplicación del modelo ha permitido:

· Evaluar calidad de producto.

· Evaluar calidad del equipo de mantenimiento.

· Posibilidad de incorporar las subcaracterísticas en la relación proveedor-cliente.

72
· Posibilidad de incorporar las subcaracterísticas en un ciclo de mejora.

· Posibilidad de incorporar las subcaracterísticas en un modelo de procesos.

· Posibilidad de incorporar requisitos de calidad asociados a la explotación del sistema.

· Posibilidad de establecer requisitos de aceptación asociados a productos y capacidad

organizativa del equipo de mantenimiento.
Moprosoft: el nuevo modelo que impondrá una norma mexicana para la calidad en
la industria del software.

En la actualidad, es indudable que el software es la herramienta que establece las

dinámicas laborales, de producción y hasta de convivencia en todo el mundo.

Los múltiples desarrollos que en este ámbito se dan –casi cotidianamente– generan
como consecuencia la necesidad de establecer cánones de calidad para cada
producto, para así garantizar que su desempeño y sus funciones cubran las
expectativas de sus consumidores y que, en la práctica, cumplan con su cometido
satisfactoriamente.

Consciente de ello, la Asociación Mexicana para la Calidad en Ingeniería de

Software (AMCIS) ha trabajado en el desarrollo de un modelo que cubra los
requisitos que la norma ISO 9000 demanda de los productos de esta naturaleza.

El Modelo de Procesos para la Industria de Software, Moprosoft, tienepor objetivo

proporcionar a la industria mexicana, y a las áreas internasdedicadas al desarrollo
y mantenimiento de software, un conjunto integradode las mejores prácticas
basadas en los modelos y estándares reconocidosinternacionalmente, tales como
ISO 9000:2000, CMM-SW, ISO/IEC 15504, PMBOK, SWEBOK entre otros.

Moprosoft contiene tres categorías de procesos que corresponden a las capas de

Alta Dirección, Gestión y Operación. La categoría de AltaDirección contiene el
proceso de Gestión de Negocio; la categoría deGestión se compone de Gestión
de Procesos, Gestión de Proyectos y Gestión de Recursos, a su vez, este último
se divide en tres subprocesos:El de Recursos Humanos, el de Bienes,
Servicios e Infraestructura y el deConocimiento de la Organizació[Link],
la categoríade Operación contiene los procesos de Administración de
Proyectos Específicos y de Desarrollo yMantenimiento de Software.

El propósito de contar con un modelo de estas características es apoyar a la

industria de software en su tránsito del estado actual, en el cual la calidad de los
productos depende principalmente de las habilidades de los individuos, al estado
deseado: en donde la calidad de los productos de software será la consecuencia de
la madurez en los procesos de las organizaciones.

73
4.3 CARACTERÍSTICAS DESEADAS DEL MODELO MOPROSOFT

 Específico para el desarrollo y mantenimiento del software.

 Fácil de entender.
 Definido como un conjunto de proceso.
 Practico de aplicar en organizaciones pequeñas.
 Orientado a mejorar los procesos para contribuir a los objetivos del negocio.

VENTAJAS DEL MODELO:

 Al tener prácticas integradas, que abarcan desde la gestión de negocio hasta

el desarrollo y mantenimiento de software, las empresas tendrían mayor
control sobre su desempeño en el mercado.
 El costo de la incorporación del nuevo personal podría disminuir si se enfocan
la educación y la capacitación a un modelo único.

 Las empresas pequeñas, al seguir procesos similares, podrían asociarse con

mayor facilidad para afrontar proyectos de mayor envergadura.
 La exportación de servicios de software de las empresas mexicanas.

ALCANCE
El modelo de procesos MoProSoft está dirigido a las empresas o áreas internas
dedicadas al desarrollo y/o mantenimiento de software. Las organizaciones, que no
cuenten con procesos establecidos, pueden usar el modelo ajustándolo de acuerdo
a sus necesidades. Mientras que las organizaciones, que ya tienen procesos
establecidos, pueden usarlo como punto de referencia para identificar los elementos
que les hace falta cubrir.

CRITERIOS EMPLEADOS:
Para la elaboración de este proceso se ha aplicado los siguientes criterios:
 La estructura de procesos resultante debe ser acorde a la estructura
generalmente empleada por las organizaciones de la industria del software
(alta dirección, gestión y operación)
 La alta dirección tiene un papel importante a través de la planificación
estratégica. Debe actuar como promotor del buen funcionamiento de la
organización a través de su implicación en la revisión y mejora continua del
modelo.
 El modelo considera a la gestión como proveedora de recursos, procesos y
proyectos; así como responsable de la vigilancia del cumplimiento de los
objetivos estratégicos de la organización.
 El modelo considera a la operación como ejecutora de los proyectos de
desarrollo y mantenimiento de software.
 El modelo integra con claridad y consistencia los elementos indispensables
para la definición de los procesos y las relaciones entre ellos.

74
  El modelo integra los elementos para realizar la administración de proyectos
desde un sólo proceso.
 El modelo integra los elementos para realizar la ingeniería de productos de
software en un único marco que incluya los procesos precisos de soporte
(verificación, validación, documentación y control de la documentación).
 El modelo destaca la importancia de la gestión de recursos, con especial
relevancia en aquellos que componen el conocimiento de la organización:
productos generados por proyectos, datos de los proyectos, mediciones,
documentación de procesos y datos cosechados a partir del uso y de las
lecciones aprendidas.

USO DEL MODELO DE PROCESOS.

Organizaciones sin procesos establecidos:

Para usar este modelo en una organización que no cuenta con procesos
establecidos ni documentados se debe generar una instancia de cada uno de los
procesos, tomando en cuenta las siguientes consideraciones:

• Definir las metas cuantitativas de acuerdo a las estrategias de la organización.

• Revisar los nombres de los roles y los productos (entradas, salidas o internos) y
en su caso sustituirlos por los que se acostumbran en la organización.
• Para cada producto definir el estándar de documentación cumpliendo con las
características mencionadas en la descripción del producto.
• Definir los recursos de infraestructura de cada proceso.
• Analizar si las mediciones de cada proceso son aplicables dentro del contexto de
organización y en su caso modificarlas.
• Usar las guías de ajuste para adecuar el proceso en función de las estrategias de
la organización.
• Posteriormente sustituir las guías de ajuste del modelo por las guías que apliquen
en la organización.

ADICIONALMENTE, PARA EL PROCESO DE DESARROLLO Y

MANTENIMIENTO DE SOFTWARE, SE REQUIERE:

• Definir métodos, técnicas o procedimientos específicos para las actividades,

tareas, verificaciones y validaciones.

ORGANIZACIONES CON PROCESOS ESTABLECIDOS:

Para usar este modelo en una organización que cuente con procesos establecidos
o documentados, se debe establecer la correspondencia entre estos procesos y el
modelo MoProSoft para identificar las coincidencias y discrepancias.
La organización debe analizar las discrepancias y planificar las actividades de ajuste
de los procesos para lograr la cobertura completa de MoProSoft.

75
IMPLANTACIÓN Y MEJORA CONTINÚA:

La organización debe establecer la estrategia de implantación de los procesos

definidos. Puede decidir probarlos en proyectos piloto o implantarlos al mismo
tiempo en toda la organización.
Con el transcurso del tiempo, los procesos deben evolucionar con base a las
sugerencias de mejora e ir alcanzando los objetivos del plan estratégico de la
organización con metas cuantitativas cada vez más ambiciosas. De esta manera la
organización puede ir logrando la madurez a través de la mejora continua de sus
procesos.

ESTRUCTURA DEL MODELO DE PROCESOS:

MoProSoft contiene tres categorías de procesos que corresponden a las capas de

Alta Dirección, Gestión y Operación. La categoría de Alta Dirección contiene el
proceso de Gestión de Negocio; la categoría de Gestión se compone de Gestión de
Procesos, Gestión de Proyectos y Gestión de Recursos, a su vez, este último se
divide en tres subprocesos: el de Recursos Humanos, el de Bienes, Servicios e
Infraestructura y el de Conocimiento de la Organización. Finalmente, la categoría
de Operación contiene los procesos de Administración de Proyectos Específicos y
de Desarrollo y Mantenimiento de Software.
A continuación se describe cada una de las categorías de procesos que
corresponde a MoProSoft:
Alta Dirección, Gerencia y Operación que reflejan la estructura de una organización.

Categoría alta dirección (DIR): Contiene el proceso de Gestión de Negocio.

Gestión de Negocio: Establece la razón de ser de la organización, sus objetivos y

las condiciones para lograrlos, para lo cual es necesario considerar las necesidades
de los clientes, así como evaluar los resultados para poder proponer cambios que
permitan la mejora continua.

Categoría Gerencia (GER): Está integrada por los procesos de Gestión de

Procesos, Gestión de Proyectos y Gestión de Recursos. Éste último está constituido
por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes,
Servicios e Infraestructura y Conocimiento de la Organización.

Gestión de Procesos: Establece los procesos de la organización, en función de los

procesos requeridos identificados en el plan estratégicas.
Así como definir, plantear, e implantar las actividades de mejora en los mismos.

76
Gestión de Proyectos: Asegura que los proyectos contribuyan al cumplimiento de
los objetivos y estrategias de la organización.

Gestión de Recursos: Se encarga de conseguir y dotar a la organización de los

recursos humanos, infraestructura, ambiente de trabajo y proveedores, así como
crear y mantener la base de conocimiento de la organización. La finalidad es apoyar
el cumplimiento de los objetivos del plan estratégico de la organización y para ellos,
contiene:
Recursos Humanos y Ambiente de Trabajo: Proporciona los recursos humanos
adecuados para cumplir las responsabilidades asignadas ha los roles dentro de la
organización.

Bienes Servicios e Infraestructura: Se encarga de proporcionar proveedores de

bienes, servicios e infraestructura que satisfagan los requerimientos de adquisición
de los procesos y proyectos.

Conocimiento de la Organización: Este se encarga de mantener disponible y

administrar la base de conocimiento que contiene la información y los productos
generados por la organización.

Categoría Operación (OPE): Está integrada por los procesos de Administración de

Proyectos Específicos y de Desarrollo y Mantenimiento de Software.
Administración de Proyectos Específicos: Establece y lleva a cabo
sistemáticamente las actividades que permita cumplir con los objetivos de un
proyecto en tiempo y costo esperado.

Desarrollo y Mantenimiento de Software: Es la realización sistemática de las

actividades de análisis, diseño, construcción, integración y pruebas de productos de
software nuevo o modificado cumpliendo con los requerimientos específicos.

El proceso de Desarrollo y Mantenimiento de Software se compone de uno o

más ciclos de desarrollo. Cada ciclo está compuesto de las siguientes fases:

Inicio: Revisión del Plan de Desarrollo por los miembros del Equipo de Trabajo para
lograr un entendimiento común del proyecto y para obtener el compromiso de su
realización.

Requerimientos: Conjunto de actividades cuya finalidad es obtener la

documentación de la Especificación de Requerimientos y Plan de Pruebas de
Sistema, para conseguir un entendimiento común entre el cliente y el proyecto.

Análisis y Diseño: Conjunto de actividades en las cuales se analizan los

requerimientos especificados para producir una descripción de la estructura de los

77
componentes de software, la cual servirá de base para la construcción. Como
resultado se obtiene la documentación del Análisis y Diseño y Plan de Pruebas de
Integración.

Construcción: Conjunto de actividades para producir componente(s) de software

que correspondan al Análisis y Diseño, así como la realización de pruebas unitarias.
Como resultado se obtienen el (los) Componente(s) de software probados.

Integración y Pruebas. Conjunto de actividades para integrar y probar los

componentes de software, basados en los Planes de Pruebas de Integración y de
Sistema, con la finalidad de obtener el Software que satisfaga los requerimientos
especificados. Se genera la versión final del Manual de Usuario, Manual de
Operación y Manual de Mantenimiento.
Como resultado se obtiene el producto de Software probado y documentado.

Cierre: Integración final de la Configuración de Software generada en las fases para

su entrega. Identificación y documentación de las lecciones aprendidas. Generación
del Reporte de Mediciones y sugerencias de mejora.
Para generar los productos de cada una de estas fases se realizan las siguientes
actividades:
Distribución de tareas, se asignan las responsabilidades de cada miembro del
Equipo de Trabajo de acuerdo al Plan de Desarrollo.
Producción, verificación, validación o prueba de los productos, así como su
corrección correspondiente.
Generación del Reporte de Actividades.

El objetivo es lograr que los productos de salida sean consistentes con los productos
de entrada en cada fase de un ciclo de desarrollo mediante las actividades de
verificación, validación o prueba.

En cada fase de un ciclo se efectúan todas las actividades de verificación,

validación o prueba, así como las correcciones correspondientes.
La Configuración de Software está integrada por los productos generados en
el ciclo.
Las actividades planificadas en cada fase de un ciclo se realizan conforme a
lo establecido en el Plan de Desarrollo.

En cada proceso están definidos los roles responsables por la ejecución de las
prácticas. Los roles se asignan al personal de la organización de acuerdo a sus
habilidades y capacitación para desempeñarlos.

78
En MoProSoft se clasifican los roles en Grupo Directivo, Responsable de Proceso y
otros roles involucrados. Además se considera al Cliente y al Usuario como roles
externos a la organización.
Fuente
Especificaciones de
actividades en proceso de
Desarrollo y Mantenimiento
de Software:

Entradas Nombre
Plan de Desarrollo Administración de Proyectos
Descripción del Producto Específicos
• Entregables
• Proceso Específico
• Equipo de Trabajo
• Calendario

79
4.4. FASE ESPECIFICACIÓN DE REQUERIMIENTOS.

Descripción: Se compone de una introducción y una descripción de

requerimientos.
Introducción:
Descripción general del software y su uso en el ámbito de negocio del cliente.
Descripción de requerimientos:
* Funcionales: Necesidades establecidas que debe satisfacer el software cuando
es usado en condiciones específicas. Las funcionalidades deben ser adecuadas,
exactas y Seguras.
* Interfaz con usuario: Definición de aquellas características de la interfaz de
usuario que permiten que el software sea fácil de entender, aprender, que genere
satisfacción y con el cual el usuario pueda desempeñar su tarea eficientemente.
Incluyendo la descripción del prototipo de la interfaz.
* Interfaces externas: Definición de las interfaces con otro software o con
hardware.
* Confiabilidad: Especificación del nivel de desempeño del software con respecto
a la madurez, tolerancia a fallas y recuperación.
* Eficiencia: Especificación del nivel de desempeño del software con respecto al
tiempo y a la utilización de recursos.
* Mantenimiento: Descripción de los elementos que facilitarán la comprensión y la
realización de las modificaciones futuras del software.
* Portabilidad: Descripción de las características del software que permitan su
transferencia de un ambiente a otro.
* Restricciones de diseño y construcción: Necesidades impuestas por el cliente.
* Legales y reglamentarios: Necesidades impuestas por leyes, reglamentos, entre
otros.

80
4.5. FASE DE ANÁLISIS Y DISEÑO:

Descripción: Este fase contiene la descripción textual y grafica de la estructura de

los componentes de software. El cual consta de las siguientes partes:
Arquitectónica:
Contiene la estructura interna del sistema, es decir la descomposición del sistema
en subsistemas. Así como la identificación de los componentes que integran los
subsistemas y las relaciones de interacción entre ellos.
Detallada:
Contiene el detalle de los componentes que permita de manera evidentesu
construcción y prueba en el ambiente de programación.

FASE COMPONENTE: Conjunto de unidades de código relacionadas.

Software: Sistema de software, destinado a un cliente o usuario, constituido por
componentes agrupados en subsistemas, posiblemente anidados.
Configuración de Software: Conjunto consistente de productos de software, que
incluye:
• Especificación de Requerimientos.
• Análisis y Diseño.
• Software.
• Registro de Rastreo.
• Plan de Pruebas de Sistema.
• Reporte de Pruebas de Sistema.
• Plan de Pruebas de Integración.
• Reporte de Pruebas de Integración.
• Manual de Usuario.
• Manual de Operación.
• Manual de Mantenimiento.

Manual de Usuario: Documento electrónico o impreso que describe la forma de

uso del software con base a la interfaz del usuario. Éste deberá ser redactado en
términos comprensibles a los usuarios.
Manual de Operación: Documento electrónico o impreso que contenga la
información indispensable para la instalación y administración del software, así
como el ambiente de operación (sistema operativo, base de datos, servidores, etc.).
Éste deberá ser redactado en términos comprensibles al personal responsable de
la operación.

81
Manual de Mantenimiento: Documento electrónico o impreso que describe la
Configuración de Software y el ambiente usado para el desarrollo y pruebas
(compiladores, herramientas de análisis y diseño, construcción y pruebas). Este
deberá ser redactado en términos comprensibles al personal de mantenimiento.

Reporte de Actividades: Registro periódico de actividades, fechas de inicio y fin,

responsables y mediciones, tales como:
• Tiempo de producción, de corrección, de verificación y de validación, Defectos
encontrados en verificación, validación o prueba,
• Tamaño de productos.

Lecciones Aprendidas: Registro de mejores prácticas, problemas recurrentes y

experiencias exitosas en la solución de problemas, encontrados en un ciclo de
desarrollo y mantenimiento.
Reporte de Mediciones y Sugerencias de Mejora:
Registro que contiene:
* Mediciones de los indicadores del proceso de Desarrollo y Mantenimiento de
Software.
* Sugerencias de mejora al proceso de Desarrollo y Mantenimiento de Software
(métodos, herramientas, formatos, estándares, etc.).

82
4.6. CMMI
CapabilityMaturityModelIntegration (CMMI) es un modelo de aseguramiento de la
calidad que busca la mejora continua de las organizaciones mediante el análisis y
re-diseño de los procesos que subyacen en la organización. Fue creado por el SEI
(Software EngineeringInstitute) de laUniversidad de Carnegie-Mellon y patrocinado
por el Ministerio de Defensa de los Estados Unidos. Con elpropósito de lograr la
mejora de los procesos, CMMI provee:
Una forma de integrar los elementos funcionales de una organización [SEI07b].
Un conjunto de mejores prácticas basadas en casos de éxito probado de
organizaciones experimentadas en la mejora de procesos.
Ayuda para identificar objetivos y prioridades para mejorar los procesos de la
organización [SEI07b], dependiendo de las fortalezas y debilidades de la
organización que son obtenidas mediante un método de evaluación.
Un apoyo para que las empresas complejas en actividades productivas puedan
coordinar sus actividades en la mejora de los procesos.
Un punto de referencia para evaluar los procesos actuales de la organización CMMI
v1.2 corresponde a la tercera versión entregable del modelo CMMI, posterior a las
versiones 1.02 (primera versión año 2000) y 1.1 (año 2002). Las versiones previas
sirvieron como retroalimentación para que los propios usuarios, evaluadores y
evaluados hicieran acotaciones sobre posibles mejoras, las cuales fueron
estudiadas, refinadas y algunas incluidas en la versión 1.2. CMMI v1.2 para
desarrollo, que corresponde a una de tres constelaciones de prácticas, es una guía
que ayuda a manejar, medir y monitorear procesos utilizados en el desarrollo de
productos y servicios de una organización, y contiene prácticas ligadas a la
administración de proyectos, administración de procesos, ingeniería y soporte. Las
otras dos constelaciones son CMMI para Adquisición que provee una guía para
liderar la adquisición informada y decisiva, y CMMI para Servicios que proporciona
una guía para la entrega de servicios a clientes internos y externos de la
organización. Ambas constelaciones se encuentran aún en desarrollo. Junto con
CMMI se desarrolló y publicó el método de evaluación
"AssessmentRequirementsfor CMMI (ARC)" [SEI00] en el año 2000, el cual define
los requerimientos considerados esenciales para realizar una evaluación de CMMI
en una organización y "Standard CMMI AppraisalMethodforProcessImprovement",
(SCAMPI) [SEI01], 5+/manual seguido por los evaluadores para medir el nivel de
madurez de una organización. Estos dosdocumentos también se han
actualizadocomo consecuencia de la retroalimentación de la comunidad involucrada
en CMMI, generando la última versión 1.2 de SCAMPI y ARC ambas publicadas el
año 2006.

83
Representaciones
La representación usada en CMMI entrega una guía para efectuar las actividades
de mejora de los procesos y es utilizada en el método de evaluación. Según el
modelo se tienen dos formas para mejorar. Una forma es mejorar un proceso
específico o un conjunto de ellos usando la Representación Continua
(ContinuousRepresentation) y la otra es la mejora de la organización completa
según los procesos definidos y ocupados usando la Representación Escalonada o
por Etapas (StagedRepresentation). En la Tabla 1 se muestran los niveles para
estos dos tipos de representaciones.
Representación Continua
La representación continua se focaliza en la mejora de un proceso o un conjuntode
ellos relacionado(s) estrechamente a un área de proceso en que una organización
desea mejorar, por lo tanto una organización puede ser certificada para un área de
proceso en cierto nivel de capacidad. Existen seis niveles de capacidad por donde
transitan los procesos asociados a un área de proceso y cada nivel es construido
sobre el nivel anterior, es decir para que un proceso alcance un nivel de capacidad
necesariamente debe haber alcanzado el nivel anterior.

Tabla 1: Niveles de Representación continua y escalonada.

Los niveles de capacidad son:

Nivel 0 - Incompleto: Un proceso es denominado "proceso incompleto" cuando una
o más objetivos específicos del área de proceso no son satisfechos.
Nivel 1 – Realizado: Un proceso es denominado "proceso realizado" cuando
satisface todos los objetivos específicos del área de proceso. Soporta y permite el
trabajo necesario para producir artefactos [Chr06].

84
Nivel 2 – Manejado: Un proceso es denominado como "proceso manejado" cuando
tiene la infraestructura base para apoyar el proceso. El proceso es planeado y
ejecutado en concordancia con la política, emplea gente calificada los cuales tienen
recursos adecuados para producir salidas controladas; involucra partes interesadas;
es monitoreado, controlado y revisado; y es evaluado según la descripción del
proceso.
Nivel 3 – Definido: Un proceso denominado "proceso definido" es adaptado desde
el conjunto de procesos estándares de la organización de acuerdo a las guías de
adaptación de la organización, y aporta artefactos, medidas, y otra información de
mejora a los activos organizacionales.
Nivel 4 – Manejado cuantitativamente: Un proceso denominado "proceso manejado
cuantitativamente" es controlado usando técnicas estadísticas y otras técnicas
cuantitativas. Objetivos cuantitativos para la calidad y realización del proceso son
establecidos y usados como criterios para manejar el proceso.
Nivel 5 – Optimización: Un proceso denominado "proceso optimización es mejorado
basado en el entendimiento de causas comunes de variación del proceso. Un
proceso en optimización se focaliza en la mejora continua del proceso realizado a
través de mejoras incrementales y usando innovacióntecnológica.
Representación Escalonada
En la representación escalonada o por etapas se ofrece un método estructurado y
sistemático de mejoramiento de procesos, que implica mejorar por etapas o niveles.
Al alcanzar un nivel, la organización se asegura de contar con una infraestructura
robusta en términos de procesos para optar a alcanzar el nivel siguiente. Por lo tanto
es una organización la que puede ser certificada bajo un nivel, en este caso llamado
nivel de madurez. Según esta representación un nivel de madurez está compuesto
por áreas de procesos (ver Tabla 2) en donde los objetivos asociados a ese nivel
deben ser cumplidos para que la organización pueda certificarse en aquel nivel de
madurez. Hay cinco niveles de madurez, los que son descritos a continuación:
Nivel 1: Iniciado
En el nivel de madurez 1, la mayoría de los procesos son "ad-hoc" y caóticos. La
organización usualmente no provee un ambiente estable para soportar los
procesos. Éxitos en estas organizaciones se debe a la competencia y esfuerzos
heroicos de la gente dentro de la organización y no al uso de procesos probados. A
pesar de este caos, organizaciones pertenecientes al nivel de madurez 1 con
frecuencia producen productos y servicios que funcionan; sin embargo, ellos
frecuentemente exceden sus presupuestos y no cumplen sus planes. Estas
organizaciones son caracterizadas por la tendencia a no cumplir sus compromisos,
al abandono de procesos durante tiempos de crisis, y a la incapacidad para repetir
sus éxitos. El Nivel 1 está caracterizado además por la realización de trabajo
redundante, por personas que no comparten sus métodos de trabajo a lo largo de

85
la organización y cuando una persona clave en un área de negocio específica dentro
de la organización se marcha, su conocimiento se va con ella y se pierde para la
organización. Es claro que el Nivel 1 es uno donde ninguna organización quiere
estar y donde por lo general la mayoría que no tiene sus procesos definidos se
encuentra.
Nivel 2: Manejado
En el nivel de madurez 2 se ordena el caos. En el nivel 2 las organizaciones se
enfocan en tareas cotidianas referentes a la administración. Cada proyectode la
organización cuenta con una serie de procesos para llevarlo a cabo, los cuales son
planeados y ejecutados de acuerdo con políticas establecidas; los proyectos utilizan
gente capacitada quienes disponen de recursos para producir salidas controladas;
se involucran a las partes interesadas; son monitoreados, controlados y revisados;
y son evaluados según la descripción del proceso. La disciplina del proceso
reflejada por el nivel de madurez 2 ayuda a asegurar que existen prácticas y los
proyectos son realizados y manejados de acuerdo a los planes documentados. En
el nivel de madurez 2 el estado de los artefactos y la entrega de los servicios siguen
planes definidos. Acuerdos son establecidos entre partes interesadas y son
revisados cuando sea necesario [Chr06]. Los artefactos y servicios son
apropiadamente controlados. Estos además satisfacen sus descripciones
especificadas, estándares, y procedimientos.
Nivel 3: Definido
En el nivel de madurez 3, procesos son caracterizados y entendidos de buena
forma, y son descritos en estándares, procedimientos, herramientas, y métodos. El
conjunto de procesos estándares de la organización, los cuales son la base para el
nivel de madurez 3, es establecido y mejorado continuamente. Estos
procesosestándares son usados para establecer consistencia a través de la
organización. Los proyectos establecen sus procesos adaptando el conjunto de
procesos estándares de la organización de acuerdo a guías de adaptación. Una
diferencia importante entre el nivel 2 y 3 es el alcance de los estándares: la
descripción de procesos y los procedimientos. En el nivel de madurez 2, los
estándares pueden ser un poco diferentes en cada instancia específica del proceso
(por ejemplo sobre un proyecto particular). En el nivel de madurez 3, los estándares,
descripción de procesos y procedimientos para un proyecto, son adaptados desde
un conjunto de procesos estándares de la organización a un particular proyecto o
unidad organizacional y así son más consistentes. Otra distinción crítica es que el
nivel de madurez 3, los procesos son típicamente descritos más rigurosamente que
en el nivel 2. Un proceso definido claramente plantea el propósito, entradas, criterios
de entrada, actividades, roles, medidas, pasos de verificación, salidas y criterios de
salida. En el nivel de madurez 3, procesos son manejados más proactivamente
entendiendo las interrelaciones de las actividades y medidas detalladas del proceso,
sus artefactos y sus servicios.

86
Nivel 4: Manejado cuantitativamente
En el nivel de madurez 4, la organización y proyectos establecen objetivos
cuantitativos para medir la calidad y realización de los procesos y los usa como
criterios en el manejo de ellos. Los objetivos cuantitativos son definidos en base a
las necesidades de clientes, usuarios finales, organización, y actores de los
procesos. La calidad y realización de procesos son entendidos en términos
estadísticos y son manejados durante todo el ciclo de vida del proceso. Para
subprocesos seleccionados, se recolectan y analizan estadísticamente medidas
sobre la realización de procesos. Estas métricas son incorporadas en el repositorio
de métricas de la organización para apoyar la toma de decisiones. Causas
especiales de variación de procesos son identificadas y, cuando sea necesario, las
fuentes de estas causas son corregidas para prevenir futuras ocurrencias. Una
diferencia importante entre los niveles 3 y 4 es la capacidad de predicción de la
realización del proceso. En el nivel de madurez 4, la realización de procesos es
controlada usando técnicas estadísticas y cuantitativas, y el proceso es
cuantitativamente predecible, en cambio en el nivel de madurez 3 la realización del
proceso es sólo predecible cualitativamente.
Nivel 5: Optimizado
En el nivel de madurez 5, una organización mejora continuamente sus procesos
basándose en el conocimiento de las causas comunes de variación inherente en los
procesos. El nivel de madurez 5 se focaliza sobre la mejora continua de losprocesos
a través de mejoras continuas, incrementales y tecnológicas. Losobjetivos de
mejora cuantitativa de procesos para la organización son establecidos,
continuamente revisados para reflejar cambios en los objetivos del negocio y usados
como criterio en la mejora de procesos. Los efectos del empleo de las mejoras de
procesos son medidos y evaluados contra los objetivos de mejora cuantitativa del
proceso.
Una diferencia importante entre el nivel de madurez 4 y 5 es el enfoque de la
variación de los procesos. En el nivel de madurez 4, la organización está orientada
a encontrar causas especiales de variación y proveer una predicción estadística de
los resultados. Sin embargo, los resultados pueden ser insuficientes para alcanzar
los objetivos establecidos. En el nivel de madurez 5 la organización está enfocada
en las causas comunes de variación de procesos y modificar los procesos afectados
para mejorar la realización de ellos y alcanzar los objetivos cuantitativos de mejora
de procesos. Dado a que la organización con que se trabajará quiere certificarse en
forma organizacional en Nivel de madurez 3, en adelante sólo se detallará el modelo
según la Representación Escalonada.

87
4.7. TENDENCIAS ACTUALES APLICADAS A LA CALIDAD
EN LOS SISTEMAS DE INFORMACION

EVOLUCIÓN DEL CONCEPTO DE CALIDAD

Se ha pasado de la obsesión por la venta a la pasión por el cliente, pasando por las
siguientes
etapas:
1º Calidad del producto: basado en las inspección, lo que conlleva a:
fabricar+inspeccionar+rechazar=aumento de costes.
2º Calidad del proceso: Fundamentado en el Control de los Procesos, mediante el
Control Estadístico de la Calidad. Se aplica sobre muestras representativas de lotes
de productos. Es la base de todo Sistema de Calidad.
3º Aseguramiento de la Calidad: Basado en considerar a la calidad como algo de
lo que todos los departamentos son responsables.
4º Gestión de la Calidad Total o Gestión Estratégica de la Calidad, son las
tendencias actuales que consideran a la calidad como parte integrante de la
estrategia global de la empresa.
Si se desea producir una buena calidad para el consumidor, es necesario decidir
por adelantado cual es la calidad de diseño, la calidad de fabricación y la calidad
que desea el cliente (diagrama de los tres círculos de calidad). Para ello se deben
de tener en cuenta los cuatro aspectos de la calidad y planificarla (Ciclo de Deming).
CONCEPTOS Y TERMINOLOGÍA DE LA CALIDAD
CALIDAD: Es el conjunto de características de una entidad que le confieren la
aptitud para satisfacer las necesidades establecida y las implícitas.
CONTROL DE LA CALIDAD: Técnicas y actividades de carácter operativo
utilizadas para cumplir los requisitos para la calidad.
ASEGURAMIENTO DE LA CALIDAD: Conjunto de acciones planificadas y
sistemáticas implantadas dentro del sistema de la calidad, para proporcionar la
confianza adecuada de que una entidad cumplirá los requisitos para la calidad.
SISTEMA DE LA CALIDAD: Es la estructura organizativa, los procedimientos, los
procesos y los recursos necesarios para llevar a cabo la gestión de la calidad.
GESTIÓN DE LA CALIDAD: Es el conjunto de actividades de la función general de
la dirección que determinan la política de la calidad, los objetivos, las
responsabilidades, y se implantan por medios tales como la planificación de la

88
calidad, el control de la calidad, el aseguramiento de la calidad y la mejora de la
calidad dentro del marco del sistema de calidad.
GESTIÓN DE LA CALIDAD TOTAL (GCT o QTM): Modo de gestión de una
organización, centrada en la calidad, basada en la participación de todos sus
miembros y dirigida al éxito a largo plazo para la satisfacción del cliente y de las
ventajas para todos los miembros de la organización y para la sociedad.
ESTANDAR ISO SPICE
El ISO/IEC 15504, también conocido como Software Process
ImprovementCapabilityDetermination, abreviado SPICE, en español,
«Determinación de la Capacidad de Mejora del Proceso de Software» es un
modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento
de sistemas de información y productos de software.
OBJETIVOS:
El proyecto SPICE tenía tres objetivos principales:
Desarrollar un borrador de trabajo para un estándar de evaluación de procesos de
software.
Llevar a cabo los ensayos de la industria de la norma emergente.
Promover la transferencia de tecnología de la evaluación de procesos de software
a la industria del software a nivel mundial.

CARACTERISTICAS:
 Establece un marco y los requisitos para cualquier procesos de evaluación
de procesos y proporciona requisitos para los modelos de evaluación de los
procesos.

 Proporciona también requisitos para cualquier modelo de evaluación de

organizaciones.

 Proporciona guías para la definición de las competencias de un evaluador

de procesos.

 Actualmente tiene 10 partes: de la 1 a la 7 completas y de la 8 a la 10 en

fase de desarrollo.

 Comprende: evaluación de procesos, mejora de procesos, determinación

de capacidad.

 Proporciona, en su parte 5, un Modelo de evaluación de procesos para los

procesos de ciclo de vida del software definidos en el estándar ISO/IEC

89
 12207 que define los procesos del ciclo de vida del desarrollo,
mantenimiento y operación de los sistemas de software.

 Proporciona, en su parte 6, un Modelo de evaluación de procesos para los

procesos de ciclo de vida del sistema definidos en el estándar ISO/IEC
15288 que define los procesos del ciclo de vida del desarrollo,
mantenimiento y operación de sistemas.

 Proporcionará, en su parte 8, un Modelo de evaluación de procesos para

los procesos de servicios TIC que serán definidos en el estándar ISO/IEC
20000-4 que definirá los procesos contenidos en la norma ISO/IEC 20000-
1.

 Equivalencia y compatibilidad con CMMI. ISO forma parte del panel

elaborador del modelo CMMI y SEI mantiene la compatibilidad y
equivalencia de ésta última con

DIMENCIONES:
Los niveles de capacidad para todo modelo de evaluación de procesos pueden
tener desde el 0 y al menos hasta el nivel 1 de los siguientes niveles de capacidad
estándar:
 Nivel 0: Incompleto

 Nivel 1: Realizado

 Nivel 2: Gestionado

 Nivel 3: Establecido

 Nivel 4: Predecible

 Nivel 5: En optimización

DIMENSIONES DE PROCESOS:
Contiene los procesos que se han de evaluar. Se corresponden con los procesos
del ciclo de vida del software. Se agrupan en categorías, en función del tipo de
actividad al cual se aplican:
CUS: Cliente-Proveedor.
ENG: Ingeniería.
SUP: Soporte.

90
 MAN: Gestión.
ORG: Organización

DIMENSIÓN DE PROCESOS CUS

La categoría CUS está formada por procesos que afecta directamente al cliente,
soportan el desarrollo y la transición del software al cliente y permiten la correcta
operación y uso del producto y/o servicio software
CUS.1 Adquisición de productos software y/o servicios
CUS.2 Establecimiento de contratos
CUS.3 Identificar las necesidades del cliente
CUS.4 Realizar auditorías y revisiones conjuntas.
CUS.5 Entrega e instalación del software.
CUS.6 Mantenimiento del software.
CUS.7 Proporcionar servicio al cliente.
CUS.8 Valorar la satisfacción del cliente.

Dimensión de procesos ENG

La categoría ENG está formada per procesos que directamente especifica,
implementa o mantienen el producto software, su relación con el sistema y su
documentación.
ENG.1 Análisis y diseño de requerimientos del sistema
ENG.2 Análisis de requerimientos del software.
ENG.3 Diseño del software.
ENG.4 Construcción del software.
ENG.5 Integración y pruebas del software.
ENG.6 Integración y pruebas del sistema.
ENG.7 Mantenimiento del software y del sistema.

91
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

DIMENSIÓN DE PROCESOS MAN

Formada por procesos utilizados en la gestión de cualquier tipo de proyecto o
proceso en el ciclo de vida del software.
MAN.1 Gestionar el proceso.
MAN.2 Gestionar el proyecto.
MAN.3 Gestionar la calidad.
MAN.4 Gestionar los riesgos.

DIMENSIÓN PROCESOS ORG

Formada por procesos que establecen los objetivos de negocio de la
organización.
ORG.1 Alineamiento de la organización.
ORG.2 Establecimiento del proceso
ORG.3 Evaluación del proceso
ORG.4 Mejora del proceso.
ORG.5 Gestión de recursos humanos.
ORG.6 Infraestructura.
ORG.7 Reutilización

92
NIVELES DE CAPACIDAD:
Nivel 0: Proceso Incompleto
El proceso no está implementado o no logra conseguir su objetivo. No hay
atributos en este nivel.

Nivel 1: Proceso Realizado

El propósito implementado logra su objetivo definido.
PA 1.1: Rendimiento del Proceso
El proceso emplea un conjunto de prácticas, que son iniciadas por unos productos
identificables y produce unos productos identificables, que satisfacen el propósito
del proceso.
Nivel 2: Proceso Gestionado
El proceso Realizado entrega productos con una calidad aceptable en un margen
de tiempo y necesidades de recursos definidos.
PA 2.1: Gestión del Rendimiento
La ejecución del proceso se gestiona para producir productos en un plazo de
tiempo y con unos requisitos preestablecidos.
PA 2.2: Gestión del Producto
La ejecución del proceso se gestiona para producir productos que se documentan
y se controlan satisfaciendo sus requisitos funcionales y no funcionales, de
acuerdo con los objetivos de calidad del producto del proceso.
Nivel 3: Proceso Establecido
El proceso Gestionado se realiza utilizando un proceso definido basado en los
principios de la ingeniería del software.
PA 3.1: Definición del Proceso
La ejecución del proceso utiliza una definición de proceso basada en un proceso
estándar, que permite contribuir a los objetivos de negocio definidos en la
organización.
PA 3.2: Recursos del Proceso
La ejecución del proceso utiliza eficazmente recursos humanos con las
habilidades adecuadas y una infraestructura de proceso que contribuyen a los
objetivos.

93
Nivel 4: Proceso Previsible
El proceso Establecido se realiza constantemente dentro de los límites de control
definidos para lograr sus objetivos.
PA 4.1: Medición del Proceso
La ejecución del proceso se soporta por los objetivos y mediciones que son
utilizadas para asegurar que la implementación del proceso contribuye a la
consecución de los objetivos.
PA 4.2: Control del Proceso
La ejecución del proceso se controla a través de la recopilación y análisis de
mediciones para controlar y corregir, donde sea necesario, el rendimiento del
proceso para lograr fiablemente los objetivos del proceso definidos.
Nivel 5: Proceso Optimizando
El proceso Previsible optimiza su rendimiento para satisfacer las necesidades de
negocio actuales y futuras y logra repetidamente satisfacer sus objetivos de
negocio definidos.
PA 5.1: Cambio de Proceso
Los cambios a la definición, gestión y rendimiento del proceso son controlados
mejor para conseguir los objetivos de negocio de la organización.
PA 5.2: Mejora Continua
Los cambios a los procesos se identifican y se implementan para asegurar la
mejora continua en el cumplimiento de los objetivos del negocio definidos de la
organización.

ESTANDAR ISO PSP/TSP

PSP (Personal Software Process)
Es un proceso de auto mejoramiento diseñado para ayudar a controlar, administrar
y mejorar la forma en que se trabaja individualmente. Es un modelo de trabajo
personal que guía al ingeniero de software para producir software de calidad de
una manera consistente y eficiente.
TSP (Team Software Process)

94
Al igual que PSP está basado en el CMM y ha sido diseñado para ayudar a
controlar, administrar y mejorar la forma en que trabaja un equipo de software. Al
igual que PSP está estructurado por formularios, guías y procedimientos para
desarrollar software.

Ventajas: Entre las ventajas a destacar de este modelo podemos mencionar la

mejora la productividad de las personas, mejora en los hábitos de programación,
se puede lograr una detección temprana de defectos y riesgos lo que deriva en
una disminución de los defectos, una mejora en la calidad, y por lo tanto, una
reducción en el ciclo de vida. Se trabaja con un plan con una base de estimación
mas certera al ser realizada por el equipo; se logra una buena comunicación entre
los integrantes.
Desventajas: Las desventajas de este modelo es que es necesario que cada uno
de los miembros tiene que tener el compromiso y la disciplina de seguir el plan.
Debe de llenar toda la documentación requerida que incluye sus registros,
planificación, las plantillas o formularios. Se debe de contar con un buen conjunto
de métricas y parámetros de calidad, lo cual, para algunas organizaciones, puede
ser difícil de definir. Cada miembro debe de estar entrenado en el PSP, si algún
miembro se va, es necesario entrenar a los nuevos miembros. Algo que puede
resultar una desventaja importante es que la Gerencia debe de dejar trabajar a los
equipos de trabajo auto dirigidos de acuerdo a sus planes, algo que no muchos
resisten.

PROCESO PERSONAL DEL SOFTWARE (PSP)

es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la
productividad personal de los programadores o ingenieros de software, en tareas
de desarrollo y mantenimiento de sistemas.
se puede considerar como la guía de trabajo personal ingenieros de software de
capacidad de procesos que implica la medición cualitativa y mejora de procesos.

FASES
psp 0: proceso base, registro de tiempos, registro de errores, estándar de tipo de
errores.
psp 0.1: estándar de codificación, medición de tamaño, propuesta, mejoramiento
del proceso.
psp 1: estimación de tiempo, reporte de pruebas.
psp 1.1: planeación de actividades, planeación de tiempos.

95
psp 2: revisión de codificación, revisión del diseño.
psp 2.1: formatos de diseño.
psp 3: desarrollo en ciclos.

PRINCIPIOS DE PSP

 los ingenieros deben planear su trabajo.

 los ingenieros deben utilizar procesos bien definidos y medidos.
 los ingenieros deben sentirse comprometidos con la calidad de sus
productos.
 cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que
encontrarlos en etapas subsecuentes.
 es más eficiente prevenir defectos que encontrarlos y arreglarlos.
 la manera correcta de hacer las cosas es siempre la manera más rápida y
barata de hacer un trabajo.

OBJETIVOS DE PSP
 lograr una disciplina de mejora continua.
 medir, estimar, planificar, seguir y controlar el proceso de desarrollo.
 en general, psp provee calidad y productividad.

MOTIVOS POR LOS QUE PSP PUEDE FALLAR SON:

 el personal de desarrollo no se involucre adecuadamente o lo suficiente en

el proyecto.
 porque puede ser que no esté consciente de la importancia del proyecto.
 porque no cuenta con los recursos suficientes o necesarios para llevar a cabo
el proyecto.
 porque la estrategia de desarrollo no es la adecuada.

96
 CARACTERÍSTICAS DE PSP
· psp se concentra en las prácticas individuales de cada ingeniero
· se caracteriza por que es de uso personal y no se recomienda para el uso de
programas de más de 10000 líneas.
· psp sirve para garantizar que se produzca software de calidad y cada ingeniero
debe garantizarla a través de su trabajo.
· psp se centra en la administración del tiempo y la administración de calidad y
prevención temprana de errores.
· psp busca involucrar al personal en el proceso de desarrollo de software.
· psp demuestra cómo manejar la calidad de sus productos desde el principio del
trabajo.

FUNCIONAMIENTO DEL TSP

TSP (Team Software Process)
Al igual que PSP está basado en el CMM y ha sido diseñado para ayudar a controlar,
administrar y mejorar la forma en que trabaja un equipo de software. Al igual que
PSP está estructurado por formularios, guías y procedimientos para desarrollar
software
Antes que los ingenieros de software puedan participar en el tsp, se requiere que ya
hayan aprendido sobre el psp, de manera tal que el tsp pueda funcionar de manera
adecuada. eltsp comienza con un proceso de cuatro días llamado despegue. el
despegue está diseñado para comenzar el proceso de construcción de los equipos y
durante éste tiempo, los equipos y sus administradores establecen metas, definen
roles, evalúan riesgos y producen un plan de equipo. el despegue generalmente se
hace con un coach específicamente entrenado, o con un líder que ya ha gerencia do
varios proyectos que han usado tsp para su desarrollo.
OBJETIVOS DEL TSP
 generar un marco basado en psp
 desarrollar productos en varios ciclos
 establecer estándares para medir la calidad y el comportamiento
 proporcionar métricas para equipos
 evaluar roles y equipos
 guías para solución de problemas en equipos

97
 PROBLEMAS COMUNES DE EQUIPOS
 falta de liderazgo
 falta de compromiso y ganas de cooperar
 diferencia en contribuciones
 falta de confianza
 falta de calidad
 mejoras excesivas
 revisiones entre colegas inefectivas

METODOLOGÍA TSP

 lanzamiento
 requerimientos
 diseño
 implementación
 integración y pruebas

98