Universidad “Mayor de San Andrés”

Ciencias Puras y Naturales

Carrera de Informática

INF 162
TRABAJO DE INVESTIGACION

Universitario:

Iván Israel Gutiérrez Huañapaco

Fecha: 13 de abril de 2022

La Paz - Bolivia
 1. MODELO CMMI PARA EL DESARROLLO V 1.3
La demanda de muchos productos hoy en día hace que cada vez sea más
integrada del funcionamiento de las organizaciones. CMMI puede reducir el
coste de la mejora de procesos en las empresas que dependen de múltiples
funciones o grupos para lograr sus objetivos.
CMMI no solo para mejora la calidad, reducir sus costes y optimizar sus plazos,
sino también para medir cómo está funcionando su programa de mejora de
procesos.
Para aplicar CMMI en su organización para la mejora de procesos, se deben
seleccionar los tres elementos siguientes:
1. El alcance en la organización.
2. El modelo.
3. La representación.

Los modelos CMMI describen las buenas prácticas que las organizaciones han
encontrado que son productivas y útiles para lograr sus objetivos de
negocio. Independientemente de su organización, debe utilizar su criterio
profesional a la hora de interpretar las buenas prácticas CMMI a su situación,
necesidades y objetivos de negocio.

Capacity Maturity Model Integration

Los modelos CMMI orientan en el desarrollo del proceso. Los modelos CMMI no
son procesos ni descripciones de proceso.
Proporciona la estructura necesaria para crear los modelos de información y los
componentes de evaluación del CMMI.
Para permitir el uso de múltiples modelos dentro del marco CMMI, los
componentes de los modelos se clasifican como comunes a todos los modelos
CMMI
Las prácticas de CMMI están diseñadas para proporcionar valor en
diferentes situaciones y, por lo tanto, se expresan en términos gene-rales. Debido
a que CMMI no recomienda ningún enfoque de desarrollo en particular, se
proporciona poca información que sea específica de un determinado enfoque.
Para ayudar a quienes utilizan métodos ágiles a interpretar las prácticas de
CMMI en sus entornos, se han añadido notas en las áreas de proceso
seleccionadas. Estas notas se añaden, generalmente en las notas introductorias,
para la siguientes áreas de proceso en CMMI-DEV: CM, PI, PMC, PP,
PPQA, RD, REQM, RSKM, TS y VER

Tales enfoques se caracterizan por lo siguiente:

• Involucración directa del cliente en el desarrollo del producto.
• Utilización de múltiples iteraciones de desarrollo para aprender y
evolucionar el producto
.• Voluntad del cliente para compartir la responsabilidad en las decisiones y
riesgos.

A muchas organizaciones les proporciona valor medir su progreso realizando una

evaluación y de esta manera conseguir una calificación de nivel de madurez o
lograr un perfil de nivel de capacidad.

Requisitos de la evaluación para Cmmi

Dependiendo del propósito de la evaluación y de la naturaleza de las
circunstancias, se puede tener preferencia por una clase u otra. Al-gunas veces
son apropiadas autoevaluaciones, evaluaciones iníciales, examen superficial o
mini evaluaciones o evaluaciones externas, en otros casos es apropiada una
evaluación de benchmarking formal.
Métodos de evaluación SCampi
El método de evaluación SCAMPI A es el método más ampliamente
aceptado y utilizado para realizar las evaluaciones ARC Clase A utilizando los
modelos CMMI. El documento Method Definition Document(MDD) de SCAMPI A
define las reglas para asegurar la consistencia de las calificaciones de la
evaluación [SEI 2011a]. Para poder realizar un benchmarking frente a otras
organizaciones, las evaluaciones deben asegurar calificaciones consistentes.
Alcanzar un nivel de madurez específico o satisfacer un área de proceso debe
significar lo mismo para las diferentes organizaciones evaluadas.

Para realizar una evaluación basada en CMMI hay que seleccionar:

• Modelo CMMI.
• Alcance de la evaluación, incluyendo la unidad de la organización a evaluar,
las áreas de proceso de CMMI a investigar y el nivel de madurez o niveles
de capacidad a evaluar.
• Método de evaluación.
• Líder del equipo de evaluación y miembros del equipo.
• Participantes de la evaluación a entrevistar seleccionados de las entidades de
la evaluación.
• Resultados de la evaluación (p. ej., calificaciones, hallazgos específicos de la
instanciación).
• Restricciones de la evaluación (p. ej., tiempo dedicado in situ).

Los siguientes principios de la evaluación para CMMI son los mismos que los
utilizados en evaluaciones para otros modelos de mejora de procesos:
• Patrocinio de la alta dirección1.
• Enfoque en los objetivos de negocio de la organización.
• Confidencialidad para los entrevistados.
• Utilización de un método documentado de evaluación.
• Utilización de un modelo de referencia de procesos (p. ej., un modelo CMMI)
 2. NORMAS ISO/IEC 25000

Es una familia de normas que tiene por objetivo la creación de un marco de trabajo
común para evaluar la calidad del producto software es el resultado de la
evolución de otras normas anteriores, especialmente de las normas ISO/IEC 9126
e ISO/IEC 14598
Se encuentra compuesta por cinco divisiones.:

• ISO/IEC 2500n –División de Gestión de Calidad

• ISO/IEC 2501n –División de Modelo de Calidad
• ISO/IEC 2502n –División de Medición de Calidad
• ISO/IEC 2503n –División de Requisitos de Calidad
• ISO/IEC 2504n –División de Evaluación de Calidad

ISO/IEC 2500n –División de Gestión de Calidad

Define todos los modelos, términos y definiciones comunes referenciados por
todas las otras normas de la familia 25000. Actualmente esta división se encuentra
formada por:
ISO/IEC 25000 -Guide toSQuaRE: contiene el modelo de la arquitectura de
SQuaRE, la terminología, un resumen de las partes, los usuarios previstos y las
partes asociadas, así como los modelos de referencia.
ISO/IEC 25001 -Planningand Management: establece los requisitos y
orientaciones para gestionar la evaluación y especificación de los requisitos del
producto software.
ISO/IEC 2501n –División de Modelo de Calidad
Presenta modelos de para calidad interna, externa y en uso del producto software.
Actualmente esta división se encuentra formada por:
ISO/IEC 25010 -Systemand software qualitymodels: describe el modelo de calidad
para el producto software y para la calidad en uso. Esta Norma presenta las
características y subcaracterísticasde calidad frente a las cuales evaluar el
producto software.
ISO/IEC25012 -Data Qualitymodel: define un modelo general para la calidad de
los datos, aplicable a aquellos datos que se encuentran almacenados de manera
estructurada y forman parte de un Sistema de Información.

ISO/IEC 2502n –División de Medición de Calidad

Actualmente esta división se encuentra formada por:
ISO/IEC 25020 -Measurementreferencemodeland guide: presenta una explicación
introductoria y un modelo de referencia común a los elementos de medición de la
calidad. También proporciona una guía para que los usuarios seleccionen o
desarrollen y apliquen medidas propuestas por normas ISO.
ISO/IEC 25021 -Qualitymeasureelements: define y especifica un conjunto
recomendado de métricas base y derivadas que puedan ser usadas a lo largo de
todo el ciclo de vida del desarrollo software.
ISO/IEC 25022 -Measurementof qualityin use: define específicamente las
métricas para realizar la medición de la calidad en uso del producto.
ISO/IEC 25023 -Measurementof systemand software productquality: define
específicamente las métricas para realizar la medición de la calidad de productos y
sistemas software.
ISO/IEC 25024 -Measurementof data quality: define específicamente las
métricas para realizar la medición de la calidad de datos.
ISO/IEC 2503n –División de Requisitos de Calidad
Las normas que forman este apartado ayudan a especificar requisitos de calidad
que pueden ser utilizados en el proceso de elicitación de requisitos* de calidad del
producto software a desarrollar o como entrada del proceso de evaluación. Para
ello, este apartado se compone de:
ISO/IEC 25030 -Qualityrequirements: provee de un conjunto de recomendaciones
para realizar la especificación de los requisitos de calidad del producto software.

ISO/IEC 2504n –División de Evaluación de Calidad

Este apartado incluye normas que proporcionan requisitos, recomendaciones y
guías para llevar a cabo el proceso de evaluación del producto software. Esta
división se encuentra formada por:
ISO/IEC 25040 -Evaluationreferencemodeland guide: propone un modelo de
referencia general para la evaluación, que considera las entradas al proceso de
evaluación, las restricciones y los recursos necesarios para obtener las
correspondientes salidas.
ISO/IEC 25041 -Evaluationguide fordevelopers, acquirersand independent
evaluators: describe los requisitos y recomendaciones para la implementación
práctica de la evaluación del producto software desde el punto de vista de los
desarrolladores, de los adquirentes y de los evaluadores independientes.
ISO/IEC 25042 -Evaluationmodules: define lo que la Norma considera un módulo
de evaluación y la documentación, estructura y contenido que se debe utilizar a la
hora de definir uno de estos módulos.
ISO/IEC 25045 -Evaluationmodule forrecoverability: define un módulo para la
evaluación de la subcaracterística Recuperabilidad.
 3. TAREAS DE LA INGENIERIA DE REQUERIMIENTOS

• Entender los requerimientos para un nuevo software es una de las tareas

más difíciles para un informático

• Debemos adaptarnos a las necesidades del proceso, producto y al equipo

conformado para realizar el software

• La ingeniería de requerimientos provee un mecanismo apropiado para

entender que quiere el consumidor, analizar sus necesidades, valorar la

factibilidad de construcción, negociar una solución razonable, especificar de

manera no ambigua una solución, validar las especificaciones y administrar

los requerimientos con forme se transforman (Capitulo 7, Pressman 2005)

Se define como un conjunto de actividades en los cuales, utilizando tecnicas y

herramientas, se analiza un problema y se concluye con la especificación de una
solución. La ingeniería de requisitos es el proceso de desarrollar una
especificación de software.
Tareas específicas:
El proceso de ingeniería de requerimientos que hay que considerar
por lo menos tres aspectos fundamentales:
• Comprender el problema
• Describir formalmente el problema
• Obtener un acuerdo sobre la naturaleza del problema
El objetivo es identificar el ámbito del proyecto general. Comienza con una
serie de conversaciones informales entre los participantes del mismo. Esta fase
suele ser acompañada de los documentos de definición de la visión global y la
visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo
mercado y se descubre un nuevo servicio.
Esto nos llevaría a simplificar el proceso a tres etapas para obtener los
requerimientos del problema que estamos atacando, estas etapas son las
siguiente:
• Elicitación de requerimientos
• Especificación
• Validación

Elicitación de requerimientos
El propósito de la elicitación de requerimientos es ganar conocimientos relevantes
del problema, que se utilizarán para producir una especificación formal del
software necesario para resolverlo. “Un problema puede ser definido como la
diferencia entre las cosas como se perciben y las cosas como se desean”
Aquí vemos nuevamente la importancia que tiene una buena comunicación entre
desarrolladores y clientes; de esta comunicación con el cliente depende que
entendamos sus necesidades. Al final de la fase de análisis de requerimientos el
analista podría llegar a tener un conocimiento extenso en el dominio del problema.

Especificación
Una especificación puede ser vista como un contrato entre usuarios y
desarrolladores de software, que define el comportamiento funcional deseado del
artefacto de software (y otras propiedades de éste, tales como performance,
confiabilidad, etc.), sin mostrar cómo será alcanzada tal funcionalidad.
Validación

La validación es el proceso que certifica que el modelo de los requerimientos es

consistente con las intenciones de los clientes y los usuarios; ésta es una visión
más general que el concepto común de validación, pues se produce en paralelo
con la elicitación y la especificación, tratando de asegurar que tanto las ideas
como los conceptos presentados en una descripción se identifican y explican con
claridad La necesidad de validación aparece cuando:
• Se incorpora una nueva pieza de información al modelo actual.
• Cuando diferentes piezas de información se incorporan en un todo coherente. La
validación no sólo se aplica al modelo final de los requerimientos, sino también a
los modelos intermedios. En la figura 1 podemos ver el esquema del proceso
planteado