TECNOLÓGICO NACIONAL DE MÉXICO

CAMPUS ACAYUCAN

Nombre del alumno:

Eliel Santos Dionisio

Nombre del docente:

José Esteban Zavala Orozco

Grado y grupo:
7to semestre “C”

Asignatura:
Calidad de los Sistemas de Información

Actividad:
Investigación Unid. 4

Fecha:
20 de Octubre de 2023

1
 Unidad IV

¨MODELOS Y ESTANDARES DE CALIDAD¨

La mejora de la calidad en las organizaciones se lleva a cabo mediante la implantación

de Sistemas de Gestión de la Calidad. Estos sistemas se diseñan teniendo en cuenta
modelos de referencia que se utilizan como una guía de los aspectos que es necesario
tener en cuenta. La finalidad primordial de estos modelos consiste en la adopción de
técnicas de gestión que lleven a la mejora continua de la organización. En los casos
mencionados a continuación, los modelos proporcionan también un sistema para la
autoevaluación y la evaluación externa de las organizaciones.

A diferencia de los modelos de calidad, los estándares de calidad tienen como fin
principal la auditoría externa de las organizaciones. Frente a la evaluación de los
modelos (que implica la valoración de los diferentes aspectos de la gestión de una
organización, asignando puntuaciones para determinar el nivel de la misma), la
auditoría establece requerimientos sin cuyo cumplimiento no puede obtenerse la
certificación correspondiente. La obtención de una certificación externa constituye una
garantía hacia terceros del adecuado funcionamiento del sistema de calidad de la
organización o unidad.

2
NORMA DE EVALUACIÓN ISO/IEC 9126

Esta norma Internacional fue publicada en 1992, la cual es usada para la evaluación
de la calidad de software, llamado “Information technology-Software product
evaluation-Quality characteristics and guidelines for their use”; o también conocido
como ISO 9126 (o ISO/IEC 9126). Este estándar describe 6 características generales:
Funcionalidad, Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad, y Portabilidad.

La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software desde
diferentes criterios asociados con adquisición, requerimientos, desarrollo, uso,
evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoria de
software. Los modelos de calidad para el software se describen así:

Calidad interna y externa: Especifica 6 características para calidad interna y externa,

las cuales, están subdivididas. Estas divisiones se manifiestan externamente cuando el
software es usado como parte de un sistema Informático, y son el resultado de
atributos internos de software.

Calidad en uso: Calidad en uso es el efecto combinado para el usuario final de las 6
características de la calidad interna y externa del software. Especifica 4 características
para la calidad en uso.

Al unir la calidad interna y externa con la calidad en uso se define un modelo de

evaluación más completo, se puede pensar que la usabilidad del modelo de calidad
externa e interna pueda ser igual al modelo de calidad en uso, pero no, la usabilidad es
la forma como los profesionales interpretan o asimilan la funcionabilidad del software y
la calidad en uso se puede asumir como la forma que lo asimila o maneja el usuario
final. Si se unen los dos modelos, se puede definir que los seis indicadores del primer
modelo tienen sus atributos y el modelo de calidad en uso sus 4 indicadores pasarían
hacer sus atributos, mirándolo gráficamente quedaría así:

Se establecen categorías para las cualidades de la calidad externa e interna y calidad

en uso del software, teniendo en cuenta estos 7 indicadores (funcionalidad,
confiabilidad, utilidad, eficiencia, capacidad de mantenimiento, portabilidad y calidad en
uso), que se subdividen a su vez en varios indicadores; estas se pueden medir por
métrica interna o externa.
3
Las definiciones se dan para cada característica y subcaracterística de calidad del
software que influye en la calidad. Para cada característica y subcaracterística, la
capacidad del software es determinada por un conjunto de atributos internos que
pueden ser medidos. Las características y subcaracterísticas se pueden medir
externamente por la capacidad del sistema que contiene el software.

FUNCIONALIDAD

Funcionalidad es la capacidad del software de cumplir y proveer las funciones para

satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones
específicas. A continuación, se muestra la característica de Funcionalidad y las
subcaracterísticas que cubre:

La funcionalidad se divide en 5 criterios:

Adecuación: La capacidad del software para proveer un adecuado conjunto de

funciones que cumplan las tareas y objetivos especificados por el usuario.

Exactitud: La capacidad del software para hacer procesos y entregar los resultados
solicitados con precisión o de forma esperada.

Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas

específicos.

Seguridad: La capacidad del software para proteger la información y los datos de

manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos para
realizar operaciones, y la capacidad de aceptar el acceso a los datos de los usuarios o
sistemas autorizados

Conformidad de la funcionalidad: La capacidad del software de cumplir los

estándares referentes a la funcionalidad.

CONFIABILIDAD

La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento

adecuado cuando es utilizando en condiciones específicas. En este caso a la
confiabilidad se amplía sostener un nivel especificado de funcionamiento y no una
función requerida.

4
La confiabilidad se divide en 4 criterios:

Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra
errores. Ejemplo, la forma como el software advierte al usuario cuando realiza
operaciones en la unidad de diskett vacía, o cuando no encuentra espacio suficiente el
disco duro donde esta almacenando los datos.

Tolerancia a errores: La capacidad que tiene el software para mantener un nivel de

funcionamiento en caso de errores.

Recuperabilidad: La capacidad que tiene el software para restablecer su

funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.

Conformidad de la fiabilidad: La capacidad del software de cumplir a los estándares

o normas relacionadas a la fiabilidad.

USABILIDAD

La usabilidad es la capacidad del software de ser entendido, aprendido, y usado en

forma fácil y atractiva. Algunos criterios de funcionalidad, fiabilidad y eficiencia afectan
la usabilidad, pero para los propósitos de la ISO/IEC 9126 ellos no clasifican como
usabilidad. La usabilidad está determinada por los usuarios finales y los usuarios
indirectos del software, dirigidos a todos los ambientes, a la preparación del uso y el
resultado obtenido.

La usabilidad se divide en 5 criterios:

Entendimiento: La capacidad que tiene el software para permitir al usuario entender si

es adecuado, y de una manera fácil como ser utilizado para las tareas y las
condiciones particulares de la aplicación. En este criterio se debe tener en cuenta la
documentación y de las ayudas que el software entrega.

Aprendizaje: La forma como el software permite al usuario aprender su uso. También

es importante considerar la documentación.

Operabilidad: La manera como el software permite al usuario operarlo y controlarlo.

Atracción: La presentación del software debe ser atractiva al usuario. Esto se refiere a
las cualidades del software para hacer más agradable al usuario, ejemplo, el diseño
5
gráfico.

Conformidad de uso: La capacidad del software de cumplir los estándares o normas

relacionadas a su usabilidad.

EFICIENCIA

La eficiencia del software es la forma del desempeño adecuado, de acuerdo a al

número recursos utilizados según las condiciones planteadas. Se debe tener en cuenta
otros aspectos como la configuración de hardware, el sistema operativo, entre otros.

La eficiencia se divide en 3 criterios:

Comportamiento de tiempos: Los tiempos adecuados de respuesta y procesamiento,

el rendimiento cuando realiza su función en condiciones específicas. Ejemplo, ejecutar
el procedimiento más complejo del software y esperar su tiempo de respuesta, realizar
la misma función, pero con más cantidad de registros.

Utilización de recursos: La capacidad del software para utilizar cantidades y tipos

adecuados de recursos cuando este funciona bajo requerimientos o condiciones
establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos.

Conformidad de eficiencia: La capacidad que tiene el software para cumplir con los
estándares o convenciones relacionados a la eficiencia.

CAPACIDAD DE MANTENIMIENTO

La capacidad de mantenimiento es la cualidad que tiene el software para ser

modificado. Incluyendo correcciones o mejoras del software, a cambios en el entorno,
y especificaciones de requerimientos funcionales.

El mantenimiento se divide en 5 criterios:

Capacidad de ser analizado: La forma como el software permite diagnósticos de

deficiencias o causas de fallas, o la identificación de partes modificadas.

Cambiabilidad: La capacidad del software para que la implementación de una

modificación se pueda realizar, incluye también codificación, diseño y documentación
de cambios.

6
Estabilidad: La forma como el software evita efectos inesperados para modificaciones
del mismo.

Facilidad de prueba: La forma como el software permite realizar pruebas a las

modificaciones sin poner el riesgo los datos.

Conformidad de facilidad de mantenimiento: La capacidad que tiene el software

para cumplir con los estándares de facilidad de mantenimiento.

Portabilidad

La capacidad que tiene el software para ser trasladado de un entorno a otro.

La usabilidad se divide en 5 criterios:

Adaptabilidad: Es como el software se adapta a diferentes entornos especificados

(hardware o sistemas operativos) sin que implique reacciones negativas ante el
cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en pantalla,
tablas, volúmenes de transacciones, formatos de reporte, etc.).

Facilidad de instalación: La facilidad del software para ser instalado en un entorno

específico o por el usuario final.

Coexistencia: La capacidad que tiene el software para coexistir con otro o varios
softwares, la forma de compartir recursos comunes con otro software o dispositivo.

Reemplazabilidad: La capacidad que tiene el software para ser remplazado por otro
software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidad de una
nueva versión es importante para el usuario, la propiedad de poder migrar los datos a
otro software de diferente proveedor.

Conformidad de portabilidad: La capacidad que tiene el software para cumplir con

los estándares relacionados a la portabilidad.

CALIDAD EN USO

Calidad en uso es la calidad del software que el usuario final refleja, la forma como el
usuario final logra realizar los procesos con satisfacción, eficiencia y exactitud. La
calidad en uso debe asegurar la prueba o revisión de todas las opciones que el usuario

7
trabaja diariamente y los procesos que realiza esporádicamente relacionados con el
mismo software.

La calidad de uso se divide en 4 criterios:

Eficacia: La capacidad del software para permitir a los usuarios finales realizar los
procesos con exactitud e integridad.

Productividad: La forma como el software permite a los usuarios emplear cantidades

apropiadas de recursos, en relación a la eficacia lograda en un contexto específico de
uso. Para una empresa es muy importante que el software no afecte a la productividad
del empleado

Seguridad: Se refiere al que el Software no tenga niveles de riesgo para causar daño
a las personas, instituciones, software, propiedad intelectual o entorno. Los riesgos son
normalmente el resultado de deficiencias en la funcionalidad (Incluyendo seguridad),
fiabilidad, usabilidad o facilidad de mantenimiento.

Satisfacción: La satisfacción es la respuesta del usuario a la interacción con el

software, e incluye las actitudes hacia el uso del mismo.

MOPROSOFT

Es el Modelo de Procesos para la Industria del Software. Un modelo para la mejora y

evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de
software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de
Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de
México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma
mexicana que resulte apropiada a las características de tamaño de la gran mayoría de
empresas mexicanas de desarrollo y mantenimiento de software.

El Programa para el Desarrollo de la Industria del Software (PROSOFT), es un plan de

la Secretaría de Economía de México que forma parte del Plan Nacional de Desarrollo
2001-2006. Y está vigente a la fecha.

PROSOFT tiene siete líneas estratégicas, siendo la sexta la que ha dado origen a
8
MoProSoft: "Alcanzar niveles internacionales en capacidad de procesos". Al comenzar
el desarrollo de esta línea estratégica se evaluó la adopción de los modelos: ISO 9000,
ISO 15504, SW-CMM. El resultado de la evaluación fue: "Ninguno de los estándares o
modelos cumple con los requisitos expresados por la industria nacional", y se decidió
la elaboración de un modelo adecuado para las características de las empresas
mexicanas, que se basaría en los modelos evaluados.

Procesos que maneja Moprosoft:

Categoría alta dirección (DIR): 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.

Gestión de Negocio

Categoría Gerencia (GER): 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:

Gestión de Proceso.

Gestión de Proyectos.

Gestión de Recursos Humanos y Ambiente de Trabajo o Bienes Servicios e

Infraestructura o Conocimiento de la Organización.

Categoría Operación (OPE): El modelo considera a la operación como ejecutora de

los proyectos de desarrollo y mantenimiento de software.

Administración de Proyectos Específicos

Desarrollo y Mantenimiento de Software.

El Programa para el Desarrollo de la Industria de Software (PROSOFT) fue

implementado en octubre de 2002.

Recursos finales.

En cada categoría se establecen roles y actividades a desarrollar, así como un

responsable, una empresa o persona se puede certificar en MOPROSOFT para poder
9
aplicar el modelo a sus desarrollos de software.

SPICE

El ISO/IEC 15504, también conocido como Software Process Improvement Capability

Determination, 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.

En 1991, dado el número creciente dre). Por tanto, el proyecto SPICE fue creado bajo
los auspicios del Comité Internacional de estándares de Ingeniería de Software y
Sistemas a través de su Grupo de Trabajo sobre Evaluación de proceso (WG10).

En 1992, el informe del grupo de estudio dijo que: “...la comunidad internacional
debería poner recursos para desarrollar un estándar para la evaluación de procesos
software, incorporando lo mejor de los métodos de evaluación de procesos existentes.”

ISO decidió entonces se hiciera el desarrollo por pasos de un estándar para la

evaluación de procesos. Los pasos fueron los siguientes:

Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de estándar”)

Revisión y publicación como estándar internacional IS ISO/IEC 15504

Tecnologías de la Información

Evaluación de Procesos (‘ISO/IEC 15504 Information Technology – Process

Assessment’).

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.
10
El primer objetivo del proyecto se logró en junio de 1995, con la entrega del borrador
de trabajo de la norma para la evaluación de procesos de software al WG10 para su
votación entre la comunidad de estandarización internacional. El Borrador de Trabajo
se denominaba comúnmente como el conjunto de documentos SPICE (o SPICE
Versión 1).

Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto
SPICE durante el período 1994 a 1998. Fue entonces, en 1998 cuando se publicó la
primera familia de estándares ISO TR 15504. En aquel momento se comenzó a
trabajar en la versión "Internacional Standard" de la norma, y desde 2006 está
completamente publicado, exceptuadas las partes nuevas que se estén produciendo.

En marzo de 2003, el proyecto SPICE se cerró oficialmente. La Red SPICE se

estableció posteriormente con el encargo de seguir coordinando las actividades de la
comunidad SPICE. La Red de SPICE está formalmente organizada por el ‘The Spice
User Grupo’ (www.spiceusergroup.org).

En este momento se efectúan actividades promocionales que se realizan a través de la

Conferencia Internacional Anual SPICE y la publicación de artículos y libros.

Con el fin de apoyar la excelencia y la coherencia de la formación de los evaluadores,

el proyecto SPICE también desarrolló y lanzó un Plan de Estudios de formación de los
evaluadores SPICE que es utilizado actualmente por el Esquema de Registro
Internacional de Evaluadores (IntRSA).

PSP/TSP

PSP (Personal Software Process), 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. Está
alineado y diseñado para emplearse en organizaciones con modelos de procesos
CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a
estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the
Personal Software Process" se dirige ahora a ingenieros juniors.

11
Se puede considerar como la guía de trabajo personal para ingenieros de software en
organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad
de procesos que implica la medición cualitativa y mejora de procesos.

Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que
tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se
orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador
cuando trabaja de forma individual.

PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre
3 niveles de la organización, los otros 2 son CMM y TSP.

El PSP amplía el proceso de mejora a la gente que realiza el trabajo de desarrollo de

software, concentrándose en las prácticas de trabajo de los ingenieros en una forma
individual, enseñando como manejar la calidad desde el principio de un producto. PSP
son nuestras propias métricas, que permiten estructurar y ordenar nuestro trabajo del
día a día. El resultado de nuestro trabajo, además puede ser llevado a un trabajo en
equipo TSP (Team Process Software), el cual es “comandado” por un sistema de
gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los
resultados y avances de los miembros del equipo.

En PSP todas las tareas y actividades que el ingeniero de software debe realizar
durante el proceso de desarrollo de un producto de software, están puntualmente
definidas en un conjunto de documentos conocidos como scripts. Los scripts son el
punto medular de PSP, por lo que se hace mucho énfasis en que deben ser seguidos
en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca.
Gran parte de las tareas y actividades definidas en los scripts generará en su
realización un conjunto de datos, fundamentalmente de carácter estadístico. La
aplicación de PSP en varios procesos de desarrollo, y el análisis de la información
estadística generada en cada uno de éstos, permitirán al ingeniero de software
identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso
de auto aprendizaje y auto mejora. La calidad en PSP, es un aspecto fuertemente
relacionado con la cantidad de defectos que el producto de software contiene.

Características:
12
Los pasos de registro de información a detalle en el nivel de medición pueden resultar
frustrantes cuando se tiene presión de tiempo.

En los scripts de PSP no se incluyen tareas y actividades para la etapa de análisis de

requerimientos.

Siempre se parte de una definición de requerimientos que no va a cambiar. Aún no

existe una herramienta automatizada que facilite el registro y análisis de datos
generados por la aplicación de PSP.

Objetivos:

PSP pretende formar ingenieros de software con métodos disciplinados para mejorar
su desarrollo personal de software. PSP le ayuda a los desarrolladores a:

Mejorar sus habilidades de estimación y planeación.

Hacer compromisos que se puedan cumplir.

Administrar la calidad de sus procesos.

Reducir la cantidad de defectos en sus producto

TSP (Team Software Process), es un método de establecimiento y mejora del trabajo

en equipo para procesos software.

TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a

planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda
establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables
y de calidad. Está formado por dos componentes primarios que abarcan distintos
aspectos del trabajo en equipo:

Formación del equipo de trabajo.

Gestión del equipo de trabajo.

Existen diferentes metodologías para la mejora de procesos, la mayoría de ellas se

basa en la mejora de los procesos que dan como resultado un servicio o producto. El
TSP busca integrar un equipo que tenga como punto de partida la unificación del
mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar
13
mejora a los procesos que desarrollan.

El Team Software Process (TSP) es un proceso de desarrollo para equipos de

ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo de software
de calidad. TSP proporciona directrices para ayudar a un equipo a establecer sus
objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la
organización pueda establecer prácticas de ingeniería avanzadas y así obtener
productos eficientes, fiables y de calidad. TSP es una solución basada en procesos
para resolver problemas de negocio, tales como:

1. Predictibilidad de costo y tiempo

2. Mejora de productividad

3. Ciclos de desarrollo y mejora de calidad de productos.

Características de los grupos eficaces:

1. Miembros expertos en papeles de liderazgo y pertenencia.

2. Relaciones tranquilas y establecidas entre los miembros.

3. Los miembros se sienten atraídos por el grupo y son fieles.

4. Los valores y metas del grupo son los de sus integrantes.

5. Los miembros están motivados por hacer lo que puedan por el grupo.

6. La interacción y toma de decisiones tiene lugar en el ambiente adecuado.

7. El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea

ayudar a cada miembro a adquirir su pleno potencial.

8. Cada miembro acepta con gusto y sin resentimiento las metas y normas
establecidas.

9. Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.

10. Existe una atmósfera de creatividad.

11. El grupo conoce el “conformismo constructivo” y se sirve de él.

14
 12. Existe gran motivación para iniciar y recibir las comunicaciones.

13. Los miembros son flexibles y adaptables en sus metas y actitudes.

14. Los miembros se sienten seguros al tomar decisiones que les Los miembros se
sienten seguros al tomar decisiones que les parecen apropiadas al entender la
filosofía de la operación.

Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process, su
antecesor) tenía en el ámbito industrial. PSP resultó muy efectivo para que los
ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus
habilidades de estimación y la reducción de los defectos introducidos en los productos
sin afectar a su productividad, pero PSP sólo se enfocaba en las fases de desarrollo de
software (diseño y pruebas unitarias); la aplicación que lo ingenieros hicieron del PSP
dentro de las empresas resulto en prácticas no satisfactorias.

Por tal motivo, Watts Humphrey desarrolló el TSP, el cual consideraba como parte
importante, además de lo previsto por el PSP, los requisitos, las pruebas de
integración, la documentación y otras actividades típicas en todo proyecto de
desarrollo, de igual manera incluía actividades como los roles de equipo,
interrelaciones dentro de la organización y la definición de un proceso de equipo para
ser utilizado dentro de los procesos existentes en la organización.

Los Roles (responsabilidades) en los equipos en STP son:

Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los
procesos y completen su trabajo tal y como se planeó. Realiza los reportes semanales
del avance del equipo.

Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.

Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del

trabajo.

Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del

proceso y a establecer y administrar el plan de calidad.

Genera estándares para obtener un trabajo uniforme. Modera las inspecciones y revisa
15
cada artefacto generado.

Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de

requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades
de apoyo administrativo.

Administra el plan de configuración.

Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP, los
equipos encuentran y reparan defectos en etapas tempranas del proceso de
desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de
manera importante el tiempo de pruebas. Con un testing más corto, el ciclo completo
se reduce.

A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como

individuos, es disciplinado y ágil, provee beneficios inmediatos y medibles y acelera las
iniciativas de mejora de procesos organizacionales.

En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se
realiza:

1. Lanzamiento

2. Estrategia

3. Plan

4. Requisitos

5. Diseño

6. Implementación

7. Pruebas

8. Postmortem

Los objetivos que tiene el TSP son:

1. Maximizar calidad software, minimizar costos.

2. Integrar equipos independientes de alto rendimiento que planeen su trabajo,

16
 establezcan metas y san sueños de sus procesos y planes.

3. Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y

como ayudarlos a alcanzar su máxima productividad.

Sus entornos son:

1. CMM- Administración.

2. TSP- Equipo Ingenieros.

3. PSP-Ingeniero.

CMMI

Integración de Modelos de Madurez de las Capacidades., es un modelo de evaluación

de los procesos de una organización. Fue desarrollado inicialmente para los procesos
relativos al software por la Universidad Carnegie-Mellon para el SEI (Software
Engineering Institute).

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas

Clave de Proceso (KPA – Key Process Area). Para cada área de proceso define un
conjunto de buenas prácticas que habrán de ser:

1. Definidas en un procedimiento documentado

2. Provistas (la organización) de los medios y formación necesarios

3. Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)

4. Medidas

5. Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco “niveles de madurez”, de modo

que una organización que tenga institucionalizadas todas las prácticas incluidas en un
nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.

Los niveles son:

17
1 – Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para
el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de
ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los
proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo
se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los
proyectos es impredecible.

2 – Repetible. En este nivel las organizaciones disponen de unas prácticas

institucionalizadas de gestión de proyectos, existen unas métricas básicas y un
razonable seguimiento de la calidad. La relación con subcontratistas y clientes está
gestionada sistemáticamente.

3 – Definido. Además de una buena gestión de proyectos, a este nivel las

organizaciones disponen de correctos procedimientos de coordinación entre grupos,
formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado
de métricas en los procesos. Se implementan técnicas de revisión por pares (peer
reviews).

4 – Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de

métricas significativas de calidad y productividad, que se usan de modo sistemático
para la toma de decisiones y la gestión de riesgos. El software resultante es de alta
calidad.

5 – Optimizado. La organización completa está volcada en la mejora continua de los

procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de
innovación.

Las prácticas que deben ser realizadas por cada área Clave de Proceso están
organizadas en 5 Características Comunes, las cuales constituyen propiedades que
indican si la implementación y la institucionalización de un proceso clave es efectivo,
repetible y duradero.

Estas 5 características son:

1. Compromiso de la realización

2. La capacidad de realización
18
 3. Las actividades realizadas

4. Las mediciones y el análisis

5. La verificación de la implementación

TENDENCIAS ACTUALES

Tendencia:

Cualquier idea religiosa, económica, política, artística, etc. Que se orienta en

determinada dirección.

Innovando el futuro.

1. Existen tres principales puntos de las nuevas tendencias.

2. Menos riesgo: APP más accesibles y menos costosas.

3. Utilización de las redes sociales dentro de las compañías: Redes sociales.

4. Llega el Internet de los objetos: Vamos a un mundo de sensores

Aceleración de la adquisición de teléfonos inteligentes:

1. Smartphones.

Computación de software alojado y nube:

2. Google's Docs

3. Mega.

4. Dropbox, etc.

Redes inalámbricas y celulares:

1. Wi-Fi.

19
BIBLIOGRFIAS

https://jonathancobianblog.blogspot.com/

https://calidad.usal.es/procesos-de-evaluacion/modelos-y-estandares-de-calidad/

https://modelos-de-evaluacion-de-recursos-
grupo6.fandom.com/es/wiki/Est%C3%A1ndares_y_modelos_de_calidad

20