guia para escritura de documento cientifico

Firmado digitalmente por Universidad
Tecnológica de Querétaro
Nombre de reconocimiento (DN):
cn=Universidad Tecnológica de Querétaro,
o=Universidad Tecnológica de Querétaro, ou,
[email protected], c=MX
Fecha: 2012.05.24 15:02:35 -05'00'
Universidad
Tecnológica de
Querétaro
UNIVERSIDAD TECNOLÓGICA DE
QUERÉTARO
Nombre del Proyecto:
Creación de una Metodología en CMMI
Empresa:
Universidad Tecnológica de Querétaro
Memoria
Que como parte de los requisitos para obtener
el título de
Ingeniero en Tecnologías de la Información y Comunicación
__________________________
Presenta
Ana Karen Rodríguez Trejo
____________________
Contreras Álvarez Adriana Yazmín
Asesor de la UTEQ
Alvarado de la Vega Jorge Ramiro
Asesor de la Empresa
Santiago de Querétaro, Querétaro
Mayo 2012
RESUMEN
Las organizaciones actualmente requieren de un marco de trabajo que
proporcione calidad a sus proyectos, el modelo CMMI proporciona un marco de
mejora que puede ayudar a una compañía en la mejora de sus procesos y su
habilidad para desarrollar, obtener y mantener productos y servicios.
Esta memoria es un reporte de actividades realizadas para la Universidad
Tecnológica de Querétaro, la Célula de Innovación y Desarrollo genera proyectos
de tecnologías de la información y automatización, esta célula necesita crear y
diseñar una metodología fundamentada en CMMI que le permita llevar a cabo el
desarrollo e implementación de los proyectos e iniciar el proceso de certificación
de la misma.
ABSTRACT
The organizations nowadays require a framework that provides quality projects,
the CMMI model provides a framework that can help the company in the
process improvement and its skill to develop, obtain and maintain products and
services.
This memory is a report of activities for the Universidad Tecnológica de
Querétaro, the Célula de Innovación y Desarrollo project creates information
technology and automation, this Célula need to create and design a methodology
based on CMMI that permit to makes the development and implementation
of projects and initiate the certification process.
INDICE
Página
RESUMEN
ABSTRACT
I. INTRODUCCIÓN ............................................................................................................................. 1
II. ANTECEDENTES ........................................................................................................................... 2
III. JUSTIFICACIÓN ............................................................................................................................ 2
IV. OBJETIVOS ................................................................................................................................... 3
V. ALCANCES ..................................................................................................................................... 3
VI. JUSTIFICACIÓN TEÓRICA ........................................................................................................... 3
VII. PLAN DE ACTIVIDADES.............................................................................................................. 4
VIII. RECURSOS MATERIALES Y HUMANOS .................................................................................. 5
IX. DESARROLLO DEL PROYECTO ................................................................................................. 6
INVESTIGACIÓN INGENIERÍA DE SOFTWARE ........................................................................... 7
CMMI (CAPABILITY MATURITY MODEL INTEGRATION) .......................................................... 16
IV. RESULTADOS OBTENIDOS ...................................................................................................... 26
XI. ANÁLISIS DE RIESGO ................................................................................................................ 26
XII. CONCLUSIONES ....................................................................................................................... 27
XIII. RECOMENDACIONES .............................................................................................................. 27
XIV. REFERENCIAS BIBLIOGRÁFICAS .......................................................................................... 28
I. INTRODUCCIÓN
En el presente reporte de estadía se documenta el desarrollo del proyecto
Metodología para certificación en CMMI, así como el manual de procesos y
manual organizacional para la CELULA DE INNOVACION Y DESARROLLO, esto
para automatizar la administración de los proyectos que se realizan dentro de la
empresa.
Esta metodología tiene como objetivo plasmar procedimientos para el
desarrollo de los proyectos que se desarrollan en la empresa, así como buenas
practicas para las personas que están a cargo de cada uno de los proyectos, esto
es para desarrollar software de calidad y en dado caso poder detectar deficiencias
a tiempo dentro de los proyectos.
La empresa Célula de Innovación y Desarrollo de la Universidad Tecnológica
de Querétaro no tiene ningún control de los proyectos que desarrolla por lo que
consecuentemente tienen retrasos en los mismos, tampoco no se contaba con
ningún procedimiento a seguir por lo que simplemente se desarrollaba software sin
ningún tipo de documentación que indicara información acerca de los proyectos.
En el siguiente documento se describe el proceso de una metodología que
ayuda a desarrollar proyectos de calidad desde su planeación hasta la entrega del
mismo.
1
II. ANTECEDENTES
La empresa Célula de Innovación y Desarrollo se dedica al desarrollo de
proyectos de tecnologías de la información, por lo que tiene diferentes proyectos
en desarrollo y futuros.
La empresa no cuenta con ningún tipo de metodología que indique los
procedimientos necesarios para desarrollar los proyectos con calidad. No se tiene
formatos de la documentación requerida donde se validen puntos importantes de
los proyectos que se desarrollan tales como la planeación, errores, pruebas o
alcances de los mismos.
III. JUSTIFICACIÓN
Siempre se ha considerado que tener una buena organización de la
información que se maneja dentro de una empresa crea una buena calidad en
cada uno de los productos que la empresa genera, así como un ambiente
administrativo mas limpio.
Desarrollando esta metodología basada en las buenas practicas de CMMI se
busca lograr una serie de procedimientos, reglas y documentos que permitan el
desarrollo integro de cada uno de los proyectos, un control absoluto de las
personas y de los proyectos que desarrollan así como un control de los accesos a
los mismos. Por lo que ayudara a tener una administración mas eficiente y evitara
perdidas de tiempo y lograr detectar deficiencias en los proyectos incluso evitar las
mismas en los software que se desarrolla.
Se decidió por CMMI ya que proporciona a la industria de software un
modelo de procesos basado en las mejores prácticas internacionales con los
siguientes beneficios:
1. Mejora la visibilidad sobre los Proyectos
2. Mejora la comunicación
2
3. Mejora la planificación
4. Reduce el Re-trabajo
5. Mejora la calidad del producto
6. Proporciona mayor conocimiento de la organización
7. Mejora el ambiente de trabajo
8. Se genera una Base de Conocimiento
9. Se tiene una visión compartida
10. Se tiene un cliente más informado
IV. OBJETIVOS
El objetivo prioritario de la Metodología basada en CMMI es tener una
herramienta que nos indique y nos guíe durante todo el desarrollo del software
desde su planeación hasta el cierre del mismo y que nos permita documentar de
una manera correcta todas las fases por las que paso el proyecto. Esto para tener
una justificación o información de los productos que se desarrollan.
V. ALCANCES
Diseñar y crear una metodología de trabajo que establezca procedimientos,
técnicas, herramientas y procesos certificados por CMMI para el desarrollo de
software y desarrollo de proyectos en tecnologías de la información.
VI. JUSTIFICACIÓN TEÓRICA
El modelo de procesos CMMI está dirigido a las empresas o áreas internas
dedicadas al desarrollo y/o mantenimiento de software.
3
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.
Uno de los objetivos principales es proporcionar a la industria de software
un modelo que se base en las mejores prácticas internacionales el cuál sea fácil
de aplicar y produzca servicios y productos de alta calidad.
VII. PLAN DE ACTIVIDADES
En este capítulo se
presenta una grafica de
Gantt con las etapas y
actividades programadas para lograr los objetivos del proyecto.
4
VIII. RECURSOS MATERIALES Y HUMANOS
Se presentan a continuación los recursos necesarios para el desarrollo del
proyecto, incluye los recursos humanos y el equipo que se requiere para
garantizar los resultados programados.
RECURSOS
MATERIALES

Equipos Portátiles

Sistema Operativo Windows (XP,
HUMANOS
3 Ingenieros en Tecnologías de la
Información y Comunicación.
Competencias específicas:
Vista o Seven)

Requerimientos mínimos:



Creación
de
proyectos
de
de
Disco Duro, al menos 10GB
tecnologías
información,
libres
mediante procesos y modelos de
calidad.
Procesador mínimo 500 MHz

256 MB de RAM
Integración e implementación de
metodologías para auditoria de
Sistemas en las Organizaciones.

Comunicación
de
ideas
y
propuestas en forma óptima y
con pensamiento crítico.

Proponer la implementación de
nuevas
tecnologías,
para
atender áreas de oportunidad e
innovación
en
las
software
de
organizaciones.

5
Desarrollo
de
sistemas
de
información
Capacidad de trabajo en equipo.

Capacidad trabajar en equipo.

Conocimiento en Metodologías
para desarrollo de Software
IX. DESARROLLO DEL PROYECTO
La creación de la Metodología para la empresa Célula de Innovación y
Desarrollo se realizo dentro de la Universidad Tecnológica de Querétaro, ubicada
en Av. Pie de la Cuesta 2501 C.P. 76148, la cual trabaja en varios proyectos de
tecnologías de la información, tal como software a la medida, implementación de
redes y proyectos de automatización, para lo cual se requiere tener una base de
trabajo que proporcione al equipo el respaldo necesario para generar proyectos
con alto nivel de calidad.
Al definir los requerimientos de la metodología la empresa solicita está sirva como
base para desarrollar todos los proyectos llevados a cabo en la Célula de
Innovación y Desarrollo, es decir no solamente basándose en la generación de
software como la mayoría de las metodologías lo hace, por lo que se genero una
investigación para poder llevar a cabo dicha solicitud.
En la investigación que se había llevado a cabo anteriormente se
encontraron las siguientes metodologías:
6
INVESTIGACIÓN INGENIERÍA DE SOFTWARE
FUNDAMENTOS.
Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques,
es decir, la aplicación de la ingeniería al software. Es la aplicación de la ingeniería
al software, ya que integra matemáticas, ciencias de la computación y prácticas
cuyos orígenes se encuentran en la ingeniería.
Surge a partir de la necesidad de tener una mejor administración en cuanto
al desarrollo de software en una organización, al implementar la ingeniería de
software se desarrollan proyectos con éxito, los proyectos son más fácil de
modificar e incluso más fácil de utilizar y rápido de construir.
Los procesos del ciclo de vida de desarrollo de software.
El proceso define un marco de trabajo para un conjunto de áreas clave de
proceso que se deben establecer para la entrega efectiva de la ingeniería de
software.
El ciclo de vida es el conjunto de fases por las que pasa el software que se
está desarrollando desde que surge la idea inicial hasta que es retirado o
remplazado.
En el ciclo de vida de desarrollo de software existen procesos principales,
de apoyo y organizativos determinados por la norma ISO 12207, la cuál define las
actividades que pueden llevarse a cabo durante el ciclo de vida del software.
Procesos principales, dan servicio a las partes principales durante el ciclo
de vida del software. Una parte principal es la que inicia o lleva a cabo el
desarrollo, operación y mantenimiento de productos software.
7
Proceso de adquisición
Proceso de suministro
Proceso de desarrollo
Proceso de operación
Proceso de mantenimiento
Procesos de apoyo, apoyan a otros procesos como parte esencial de los
mismos, con un propósito bien definido, y contribuyen al éxito y calidad del
proyecto software.
Proceso de documentación
Proceso de gestión de la configuración
Proceso de verificación
Proceso de validación
Proceso de revisiones conjuntas
Proceso de auditoría
Proceso de solución de problemas, se emplean por una organización para
establecer e implementar una infraestructura construida por procesos y personal
asociado al ciclo de vida, y para mejorar continuamente esta estructura y
procesos.
Proceso de gestión
Proceso de infraestructura
Proceso de mejora
Proceso de formación
Etapas del ciclo de vida de desarrollo de software:

Análisis de Requisitos/ Requerimientos
8
La primera etapa para crear un producto de software es extraer los
requisitos, en esta etapa la participación del cliente es importante ya que ellos
deciden lo que el software tiene que hacer, sin embargo se requiere habilidad y
experiencia para reconocer los requisitos que realmente el software debe cumplir.
Se debe usar el documento Especificación de Requisitos para mostrar el
resultado del análisis de requisitos con el cliente, también debe definirse un
diagrama entidad/relación para indicar las principales entidades en el desarrollo
de software.
La captura, análisis y especificación de requerimientos (incluso pruebas de
ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los
objetivos finales. Se han ideado modelos y diversos procesos de trabajo para
estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de
requerimientos.

Especificación
Describe detalladamente el software que se va a desarrollar, esta etapa del
ciclo de vida es más importante para las interfaces externas que son las que
deben permanecer estables.
Gran parte del éxito de un proyecto de software radicará en la identificación
de las necesidades del negocio (definidas por la alta dirección), así como la
interacción con los usuarios funcionales para la recolección, clasificación,
identificación, priorización y especificación de los requisitos del software.

Diseño y arquitectura
La integración de infraestructura, desarrollo de aplicaciones, bases de datos
y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser
conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El
rol en el cual se delegan todas estas actividades es el del Arquitecto.
9
El arquitecto de software es la persona que añade valor a los procesos de
negocios gracias a su valioso aporte de soluciones tecnológicas.
La arquitectura de sistemas en general, es una actividad de planeación, ya
sea a nivel de infraestructura de red y hardware, o de software.
La arquitectura de software consiste en el diseño de componentes de una
aplicación (entidades del negocio), generalmente utilizando patrones de
arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre
las entidades del negocio y además poder ser validado, por ejemplo por medio de
diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se
construirá una aplicación de software. Para ello se documenta utilizando
diagramas.

Programación
El diseño se implementa a código, no necesariamente es la que requiere
mayor trabajo, la complejidad y duración depende de los lenguajes de
programación utilizados y el diseño realizado con anterioridad.
Reducir un diseño a código puede ser la parte más obvia del trabajo de
ingeniería de software, pero no necesariamente es la que demanda mayor trabajo
y ni la más complicada. La complejidad y la duración de esta etapa está
íntimamente relacionada al o a los lenguajes de programación utilizados, así como
al diseño previamente realizado.

Prueba
Esta etapa consiste en comprobar que el software realice las tareas
indicadas en la especificación del problema.
10
Una técnica de prueba es probar por separado cada módulo del software, y
luego probarlo de forma integral, para así llegar al objetivo. Se considera una
buena práctica el que las pruebas sean efectuadas por alguien distinto al
desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo
anterior el programador debe hacer sus propias pruebas.
En general hay dos grandes formas de organizar un área de pruebas, la
primera es que esté compuesta por personal inexperto y que desconozca el tema
de pruebas, de esta forma se evalúa que la documentación entregada sea de
calidad, que los procesos descritos son tan claros que cualquiera puede
entenderlos y el software hace las cosas tal y como están descritas.
El segundo enfoque es tener un área de pruebas conformada por
programadores con experiencia, personas que saben sin mayores indicaciones en
qué condiciones puede fallar una aplicación y que pueden poner atención en
detalles que personal inexperto no consideraría.

Mantenimiento
Es la etapa donde se implementan mejoras al software para solucionar
errores descubiertos y tratar con nuevos requisitos. En esta fase del ciclo de vida
existen cuatro tipos de mantenimiento:
Perfectivo (mejora la calidad interna de los sistemas)
Evolutivo (incorporaciones, modificaciones y eliminaciones necesarias en un
producto de software para cubrir la expansión o cambio en las necesidades del
usuario)
Adaptativo (modificaciones que afectan a los entornos en los que el sistema opera,
un ejemplo son los cambios de configuración del hardware, software, gestores de
base de datos)
11
Correctivo (corrección de errores)
LA NECESIDAD DE UNA METODOLOGÍA DE DESARROLLO.
Las metodologías de desarrollo surgen a partir de la necesidad de completar
una serie de tareas para construir un proyecto de software.
Una metodología es un conjunto integrado de técnicas y métodos que permiten
empezar cada una de las actividades del ciclo de vida de un proyecto de
desarrollo de software, estas definen roles y actividades.
Una metodología está formada por:

Fases, tareas que se realizan en cada etapa.

Productos de cada fase.

Procedimientos y herramientas, sirven de apoyo para la realización de cada
tarea.

Criterios de evaluación del proceso y del producto, sirven para saber si se
han logrados los objetivos.
EVOLUCIÓN DE LAS METODOLOGÍAS DE DESARROLLO.
Clasificación de las metodologías.
Se clasifican en dos grupos; tradicionales que son las que se basan en una
fuerte planificación durante todo el desarrollo y las metodologías ágiles en las que
el desarrollo de software es incremental, cooperativo, sencillo y adaptado.
Metodologías tradicionales.
Estas metodologías se centran en llevar una documentación íntegra de todo
el proyecto y son denominadas como metodologías pesadas.
Metodologías ágiles.
12
Nace en respuesta a los problemas que llegan a ocasionar las
metodologías tradicionales, se basa en atrasar las decisiones y la planificación
adaptativa.
Estas metodologías ponen de relevancia que la capacidad de respuesta a un
cambio es más importante que el seguimiento estricto de un plan.

Metodología de desarrollo rápido de aplicaciones (RAD)
Se desarrollo para responder a la necesidad de entregar sistemas muy
rápido, sin embargo no es apropiado para todos los proyectos, el éxito de un
proyecto basado en RAD lo determina el alcance, tamaño y circunstancias del
mismo.
El método RAD tiene una lista de tareas y una estructura de desglose de
trabajo diseñada para la rapidez, comprende el desarrollo iterativo, construcción
de prototipos y el uso de utilidades CASE.
El método RAD es una fusión de varias técnicas estructuradas,
especialmente la ingeniería de información orientada a datos con técnicas de
prototipos para acelerar su desarrollo de proyectos.
RAD hace uso interactivo de técnicas estructuradas y prototipos para definir
los requisitos de usuario y diseñar el sistema final, el desarrollador construye
primero modelos de datos y procesos de negocio preliminares de los requisitos,
los prototipos ayudan al analista y los usuarios a verificar requisitos y refinar
formalmente los modelos de datos y procesos.

Metodología de proceso unificado Rational (RUP)
Es un marco de trabajo de proceso de desarrollo de software iterativo,
incluye una base de conocimiento con ejemplos y descripciones detalladas para
13
diferentes tipos de actividades, este es los resultados de la combinación de varias
metodologías y está influenciado por el modelo en espiral.

Metodología Scrum

Scrum es un proceso incremental iterativo para desarrollar cualquier
producto o gestionar cualquier trabajo. Se puede usar para gestionar y controlar
desarrollos complejos de software y productos usando prácticas iterativas e
incrementales, estaba previsto que fuera para la gestión de proyectos de
desarrollo de software, se puede usar también para la ejecución de equipos de
mantenimiento de software o como un enfoque de gestión de programas.

Metodología Extreme Programming (XP)
En esta metodología se considera que se puede ser capaz de adaptarse a
los cambios de requisitos en cualquier punto de la vida del proyecto, se cree que
es más realista que intentar definir todos los requisitos al comienzo del proyecto e
invertir esfuerzos después de controlar los cambios en los requisitos.
Se considera la programación extrema como la adopción de las mejores
metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto y aplicarlo de manera dinámica durante todo el ciclo de vida. Está
metodología se centra en la retroalimentación continua con el cliente y el equipo
de desarrollo.
Los roles propuestos para esta metodología son:
Programador: escribe las pruebas unitarias y produce el código del sistema
Cliente: escribe las historias de usuario y las pruebas funcionales para
validar su implementación. Asigna la prioridad a las historias de usuario y decide
14
cuáles se implementan en cada iteración centrándose en apoyar mayor valor al
negocio.
Encargado de pruebas (tester): ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo
y es responsable de las herramientas de soporte para las pruebas.
Encargado de seguimiento (tracker): proporciona realimentación al equipo,
Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real
dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso
de cada iteración.
Entrenador (coach): es el responsable del proceso global. Debe proveer
guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso
correctamente.
Consultor: es un miembro externo del equipo con un conocimiento
específico en algún tema necesario para el proyecto, en el que puedan surgir
problemas.
Gestor (bigboss): es el vínculo entre clientes y programadores, ayuda a que
el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor
esencial es de coordinación.

Metodología Proceso Ágil Unificado (Agile UnifiedProcess - AUP)
Describe un enfoque simple, fácil de entender, del desarrollo de software de
aplicación de negocios usando técnicas y conceptos ágiles. AUP aplica técnicas
ágiles incluyendo desarrollo orientado a pruebas, modelado ágil, gestión de
cambios ágil y refactorización de bases de datos para mejorar la productividad.
AUP se presenta en cuatro fases:
15
Inicio: el objetivo es identificar el alcance inicial del proyecto, una
arquitectura potencial para el sistema y obtener fondos y aceptación por parte de
las personas involucradas en el negocio.
Elaboración: el objetivo es probar la arquitectura del sistema.
Construcción: el objetivo es construir software operativo de forma
incremental que cumpla con las necesidades de prioridad más altas de las
personas involucradas en el negocio.
Transición: el objetivo es validar y desplegar el sistema en el entorno de
producción.
CMMI (CAPABILITY MATURITY MODEL INTEGRATION)
Integración de modelos de madurez de capacidades o Capability maturity
model integration (CMMI) es un modelo para la mejora y evaluación de procesos
para el desarrollo, mantenimiento y operación de sistemas de software.
Las mejores prácticas CMMI se publican en los documentos llamados
modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de
CMMI: Desarrollo, Adquisición y Servicios.
La versión actual de CMMI es la versión 1.3 la cual corresponde a CMMISVC, liberada el 1 de noviembre de 2010. Hay tres constelaciones de la versión
1.2 disponible:

CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión
1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo
de productos y servicios.

16

CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2
fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena
de suministro, adquisición y contratación externa en los procesos del
gobierno y la industria.

CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para
cubrir todas las actividades que requieren gestionar, establecer y entregar
Servicios.
Dentro de la constelación CMMI-DEV, existen dos modelos:

CMMI-DEV

CMMI-DEV + IPPD (Integrated Product and Process Development)
Independientemente de la constelación\modelo que opta una organización,
las prácticas CMMI deben adaptarse a cada organización en función de sus
objetivos de negocio.
Las organizaciones no pueden ser certificadas CMMI, una organización es
evaluada, usando un método de evaluación, recibe una calificación de nivel 1-5 si
sigue los niveles de madurez. En caso de que quiera la organización, puede
escoger áreas de proceso y en vez de por niveles de madurez podrá obtener los
niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil
de Capacidad" de la Organización.
AREAS DE PROCESO DE NIVEL 2.
Estas ideas se materializan en las siguientes áreas de proceso:

Gestión de Requisitos

Planificación de proyectos

Monitorización y Control de proyectos

Medición y Análisis
17

Aseguramiento de la calidad

Gestión de la configuración
Pasaremos a explicar cada una de las áreas de proceso con un poco más de
detalle:
CMM-CMMI: GESTIÓN DE REQUISITOS O REQUERIMIENTOS
El objetivo de la gestión de requisitos es gestionar los requisitos de los
elementos del proyecto y sus componentes e identificar inconsistencias entre
estos requisitos, el plan de proyectos y los elementos de trabajo.
En este proceso se deben de gestionar todos los requisitos del proyecto,
tanto los requisitos técnicos como los requisitos no técnicos.
Estos requisitos han de ser revisados conjuntamente con la fuente de los
mismos así como con las personas que se encargarán del desarrollo posterior.
CMM-CMMI: PLANIFICACIÓN DE PROYECTOS
El objetivo de la planificación de proyectos es establecer y mantener planes
que define las actividades del proyecto.
Las tareas que conlleva la planificación de proyectos son:

Desarrollar un plan inicial del proyecto

Establecer una relación adecuada con todas las personas involucradas en
el proyecto

Obtener compromiso con el plan

Mantener el plan durante el desarrollo del proyecto
18
El plan incluye estimación de los elementos de trabajo y tareas, recursos
necesarios, negociación de compromisos, establecimiento de un calendario, e
identificación y análisis de los posibles riesgos que pueda tener el proyecto.
El plan de proyectos es un herramienta de trabajo viva que se debe de
actualizar con mucha frecuencia ya que los requisitos cambiarán, habrá que
estimar, habrá riesgos que desaparezcan y otros nuevos, habrá que tomar
acciones correctivas.
CMM-CMMI: MONITORIZACIÓN Y CONTROL DE PROYECTOS
El objetivo de la monitorización y control de proyectos es proporcionar una
compresión del estado del proyecto para que se puedan tomar acciones
correctivas cuando la ejecución de proyecto se desvíe del plan.
El documento del plan de proyecto es la base para monitorizar las
actividades, comunicar el estado y tomar acciones correctivas. El progreso se
determina comparando los actuales elementos de trabajo: tareas, horas
realizadas, coste y calendario actual, con los estimados en el plan de proyecto.
Una apropiada visibilidad nos permitirá tomar acciones correctivas antes de que el
trabajo real se desvíe mucho del plan.
Estas acciones que tomaremos, harán que tengamos que rehacer/ajustar
nuestro plan de proyectos.
CMM-CMMI: MEDICIÓN Y ANÁLISIS
El objetivo de la medición y el análisis es desarrollar y sostener una
capacidad de medición que sea usada para ayudar a las necesidades de
información de la gerencia.
Los datos tomados para la medición deben estar alineados con los objetivos
de la empresa para proporcionar información útil a la misma.
19
Se ha de implantar un mecanismo de recogida de datos, almacenamiento y
análisis de los mismos de forma que las decisiones que se tomen puedan estar
basadas en estos datos.
Este sistema tiene que permitir además:

Planificación y estimación objetiva

Comparar el rendimiento actual contra el rendimiento esperado en el plan

Identificar y resolver problemas relacionados con los procesos

Proporcionar una base para añadir métricas en procesos futuros
CMM-CMMI: ASEGURAMIENTO DE LA CALIDAD
El objetivo del aseguramiento de la calidad es proporcionar personas y
gestión con el objetivo de que los procesos y los elementos de trabajo cumplan los
procesos.
Esto se consigue mediante:

Evaluar objetivamente la ejecución de los procesos, los elementos de
trabajo y servicios contra las descripciones de procesos, estándares y
procedimientos.

Identificar y documentar los elementos no conformes.

Proporcionar información a las personas que están usando los procesos y a
los gestores, de los resultados de las actividades del aseguramiento de la
calidad.

Asegurar de que los elementos no conformes son arreglados.
Esta es un área de proceso clave, que a veces no se le da la suficiente
importancia, pero que sin ella no será posible implanta un modelo de calidad.
CMM-CMMI: GESTIÓN DE LA CONFIGURACIÓN
20
El objetivo de la gestión de la configuración es establecer y mantener la
integridad de los elementos de trabajo identificando, controlando y auditando
dichos elementos.
Más concretamente mediante:

La identificación de los elementos de trabajo que componen una línea base.

Controlando los cambios de dichos elementos

Proporcionando formas de construir los elementos de trabajo a partir del
sistema de control de la configuración

Mantener la integridad de las líneas base

Proporcionar información precisa de los datos de la configuración a
desarrolladores y clientes.
Esto quiere decir que es necesario tener un sistema de control y gestión de
versiones
21
FASE DESARROLLO
Establecimiento aéreas y roles
Para crear la metodología lo primero que se tuvo que realizar es establecer
las áreas donde se aplicara y los roles que esto conlleva por lo que se realizo el
Manual organizacional, Manual de procedimientos de áreas y el cronograma del
CID-TAI, así también el Manual de Perfiles donde se define cada rol que estará
participando el las áreas y en la metodología desarrollada.
A continuación en la figura 1 se muestra el organigrama del CID-TAI y los
roles que se propusieron.
Coordinación
General
Área comercial
Soporte
Admón. de
Calidad
Finanzas
Compras y
Almacén
Medida y
Análisis
Recursos
Humanos
Desarrollo de
Proyectos
Figura 1. Organigrama Organizacional
22
Los roles propuestos para la metodología son:
ROL
Administrador de Proyectos
RESPONSABILIDADES
Planificar,
coordinar
y
dirigir
las
actividades de desarrollo de sistemas
así también negociación con clientes.
Analista
Analizar,
sistemas
desarrollar
de
y
mantener
información
y
automatización
Líder de Proyectos
Asistir en el desarrollo de los
sistemas de información
Su misión es la de dirigir y coordinar los
proyectos
de
desarrollo
y
mantenimiento de las aplicaciones de
un área de la empresa, supervisando
las funciones y los recursos de análisis
funcional, técnico y programación, con
el fin de satisfacer las necesidades de
los usuarios y asegurando la adecuada
explotación de las aplicaciones.
Programador
Asistir en el desarrollo de sistemas de
información y Automatización
Gerente calidad
Crear metodología y procesos para
asegurar el desarrollo de proyectos con
calidad, crear documentación de los
mismos y hacer los cambios según las
necesidades del centro, verificar que se
implemente
23
correctamente
la
metodología
y
asegurar
su
buen
funcionamiento.
Creación de fase Iniciación
Para entrar en materia después de toda una investigación y establecimiento
de áreas y roles que participaran, tomando siempre en cuenta los lineamientos de
CMMI y RUP como Ingeniería de Software se crea la fase de iniciación para la
metodología que se implementara en el CID-TAI. A continuación se presenta el
procedimiento general para la Fase de Iniciación.
1.
Cliente solicita proyecto
2.
Gerente comercial se entrevista con cliente para identificar
requerimientos
3.
Gerente comercial genera el formato ESPECIFICACION DE
REQUERIMIENTOS y se genera FORMATO PROTOTIPO
4.
Cliente acepta requerimientos y prototipo
5.
Gerente solicita colaboradores de equipo de trabajo con el
documento SOLICITUD DE PERFIL.
6.
Se asigna equipo de trabajo
7.
Gerente comercial y líder de proyecto analiza requerimientos y crean
PROPUESTA TÉCNICA
8.
Líder de proyecto analiza los riesgos y genera PROCEDIMIENTO
GESTION DE RIESGOS.
9.
Gerente
comercial
y
área
ECONÓMICA.
24
financiera
crean
PROPUESTA
10.
Gerente comercial envía propuestas y riesgos a cliente y obtiene
aceptación y se firma contrato (generar formato CONTRATO)
y
CASO DE NEGOCIO.
11.
Gerente comercial solicita Auditorias al área de Administración de
calidad de la empresa.
12.
Líder de proyecto genera PLAN DE TRABAJO, CRONOGRAMA y
GESTION DE RIESGOS
13.
Líder de proyecto con el equipo asignado generan un modelo inicial
plasmándolo en el FORMATO CASOS DE USO.
Productos generados:
Especificación de Requerimientos
Formato Prototipo
Solicitud de Perfil
Propuesta Técnica
Propuesta Económica
Contrato
Plan Desarrollo Proyecto
WBS
Cronograma
Casos de Uso
PROCEDIMIENTO Gestión de Riesgos
25
Formato Gestión de Riesgos
Formato Reporte de Riesgos
IV. RESULTADOS OBTENIDOS
Actualmente se entregaron los procedimientos y los formatos que la
empresa (Universidad Tecnológica del Estado de Querétaro) necesita para llevar
a cabo su certificación basándose en CMMI nivel 2.
Se realizaron de una forma sencilla pero completa para que el personal
que va trabajar con estos documentos no tenga inconvenientes al utilizarlos.
Es importante aclarar que el proyecto fue modificado a casi un mes y
medio de terminar la estadía profesional se había mencionado anteriormente
trabajar con Moprosoft y se modificó a CMMI por ello se llegó a un acuerdo tanto
con los profesores que nos tutoraban y se coincidió en que solo sería el nivel 2 de
CMMI.
XI. ANÁLISIS DE RIESGO
En este caso el riesgo más contundente fue que se modificó el proyecto a
poco tiempo de terminar la estadía profesional y que los avances generados eran
con la metodología anteriormente solicitada.
Con el proyecto los riesgos pueden ser esperados o inesperados, lo más
grave sería que la empresa no estuviera preparada para poder salir de este tipo
de inconvenientes.
26
Riesgo
Nivel del Riesgo
Cambio de Requerimientos
Alto
Enfermedad de programador
Media
Incumplimiento de contrato
Alto
Mal uso de información
Alto
XII. CONCLUSIONES
Se entregó a la Universidad Tecnológica del Estado de Querétaro una
metodología basada en CMMI, acompañada de técnicas, procedimientos y
procesos certificados con los cuales van a poder realizar software con la
tranquilidad de que sus productos van a contar con la calidad que se necesita
para estar al nivel de grandes industrias.
XIII. RECOMENDACIONES
1. Se recomienda tener un plan de contingencia de riesgos
2. Respaldo de formatos, procedimientos y proyectos.
3. Mesa de trabajo.
4. Juntas Efectivas (cliente-empresa)
5. Dejar claros los requerimientos con el cliente desde un inicio para
que al transcurso del tiempo no se generen inconvenientes que
afecten el factor del tiempo.
6. Personal asignado para manejo de información confidencial.
27
XIV. REFERENCIAS BIBLIOGRÁFICAS
(García, 2001)
García Romero, Claudia. “El Modelo de Capacidad de Madurez y su aplicación en
Empresas
Mexicanas
de
Software”.
Tesis
de
Maestría
en
Sistemas
Computacionales. Universidad de las Américas-Puebla. Mayo 2001.
(Moreno, 2004)
Moreno Álvarez, José Luis. “Aplicación de un Sistema Experto para el desarrollo
de Sistema Evaluador del modelo Capability Maturity Model (CMM) niveles dos y
tres.” Tesis de Maestría en Sistemas Computacionales. Universidad de las
Américas-Puebla. Mayo 2004
(Royce, 2002).
Royce, Walker. “CMM vs CMMI: From Conventional to Modern Software
Management”. Rational Software, 2002.
Carnegie Mellon Software Engineering Institute, CMMi® for Development Version
1.2, CMMi-DEV, V 1.2, CMU/SEI-2006-TR-008
Project Management Institute, A Guide to the Project Management Body of
Knowledge 4th Edition, 2004.
Morales, Mauricio F., Diplomado en Gerencia de ProyectosSobre la Base
Metodológica del PMBOK®, 2001 – 2009, U-Mynd Ltda.
Sherer, Wayne. Contrasting CMMi and the PMBOK®, CMMi Technology
Conference and User Group, Noviembre 2005.
Sherer, Wayne / Thrasher, Sandy. CMMi and PMBOK® Mappings, 2005.
28