Modelo desarrollo de software DAC
1. Características del modelo de desarrollo de software DAC
El modelo DAC define un proceso de desarrollo de software que combina las metas y
prácticas de las áreas de procesos de CMMI-DEV con las buenas prácticas de la
dirección y desarrollo ágil de proyectos de software. Es un proceso colaborativo, recursivo-iterativo, incremental
y guiado por procesos y requisitos.
Su modelo
del proceso es una adaptación del modelo en Cascada a los modelos Programación
Extrema y Desarrollo Concurrente,
incorporando elementos de los modelos Incremental
y Evolutivo en cada iteración. Está enfocado a proyectos medianos y proyectos grandes divididos en sub-proyectos que desarrollan software de gestión basado en componentes. Para determinar si un proyecto es grande, mediano o pequeño nos basamos en complejidad del proyecto y tamaño de la organización.
DAC plantea
que el problema una vez identificado y definido mediante el alcance del
producto debe ser descompuesto en problemas más pequeños, y si es necesario,
realizar con estos la misma operación. Cada sub-problema será resuelto mediante
un componente y el problema resuelto será el software o producto final. En cada
Sprint se abarca el desarrollo de
una Entrega desde el proceso de
Análisis y Diseño de Alto Nivel hasta el proceso de Transición del Producto, en
el que habrá obligatoriamente un incremento
de la versión del producto. Dentro
de cada entrega se realiza una iteración
por cada componente en la que habrá obligatoriamente un incremento de la versión del componente
el cual se desarrolla también de forma evolutiva.
Esto quiere decir que para la primera entrega se puede desarrollar la primera
versión de un componente mediante el desarrollo de los requisitos de mayor prioridad asociados a este, y ya en la segunda
entrega se puede realizar una segunda versión del componente al incorporarle
los requisitos de menor prioridad. En
cada fase (ejecución de un proceso
del ciclo de vida) se definirá como mínimo un hito para alcanzar. Al
finalizar cada iteración se realiza la integración
del componente al producto obtenido hasta el momento realizando pruebas de integración. Las iteraciones
no tienen que desarrollarse todas al mismo tiempo de forma obligatoria sino que
al contar con un equipo pequeño este se va a ir moviendo de una iteración a
otra a medida que estas vayan terminando de acuerdo a un orden de prioridad
establecido en el plan del proyecto.
2. Modelo del proceso DAC
El modelo
define en su ciclo de vida 8 procesos: Inicio
del Proyecto, Análisis y Diseño de
Alto Nivel, Desarrollo de Requisitos,
Construcción del Producto, Cierre de Iteración, Liberación del Producto, Transición del Producto y Cierre del Proyecto, ocurriendo las
iteraciones concurrentes entre los procesos de Desarrollo de Requisitos,
Construcción del Producto y Cierre de Iteración. Además entre los procesos de Desarrollo
de Requisitos y Construcción del Producto puede ocurrir un ciclo pues a medida
que los requisitos son descritos estos pueden ir entrando al proceso de
Construcción del Producto.
El modelo
tiene también dos áreas de procesos de
protección: Gestión de Proyectos
y Soporte cuyas tareas están
presentes en todos los procesos del ciclo de vida.
En las
áreas de proceso de protección se incorporan las áreas de proceso de CMMI de
las categorías Gestión de proyectos y Soporte que decida cada proyecto
distribuyéndose entre estas dos las áreas de Gestión de procesos también a
decisión del proyecto. De la misma forma las áreas de proceso de la categoría Ingeniería
se incorporan a los procesos del ciclo de vida mediante las Disciplinas de Ingeniería. En la Fig. 1
se puede ver el modelo del proceso DAC.
Fig. 1 Modelo de proceso de la metodología DAC
Una imagen más detallada de los
componentes de la metodología se muestra en la Fig. 2. En esta imagen se
encuentran entre paréntesis las siglas de las áreas de proceso de CMMI. Es decisión de cada organización decidir
qué áreas de proceso desarrolla junto a la metodología pero DAC exige que
mínimo se apliquen las áreas de proceso del nivel 2 de CMMI para cumplir con el
enfoque de calidad de la
metodología.
Para una mejor comprensión del modelo en
la Fig. 3 se muestra como sería el ciclo de vida de un producto aplicando este
modelo. El proceso DAC es un proceso recursivo que divide el problema en
componentes de software, el desarrollo
de cada componente se realizará por separado en las Iteraciones. Cada
versión del producto ejecutará una actualización
de los productos de trabajo obtenidos en los procesos Análisis y Diseño de
Alto Nivel, Liberación del Producto y Transición del Producto. Por su parte las
Áreas de Procesos de Protección de Gestión de Proyectos y Soporte tendrán
definidas un conjunto de actividades
periódicas y eventuales que se desarrollarán en los momentos planificados
por el proyecto.
Fig.2 Componentes de la metodología DAC
Fig. 3 Ciclo de Vida del Software en
DAC.
Definiendo las prácticas
1. Aplicación de los valores y principios del manifiesto ágil
Fueron 17 los que firmaron en Lake City
el Manifiesto Ágil en el año 2001 dentro de los que destacan Kent Beck y Martin
Fowler. A continuación se explica cómo aplicar cada uno de los valores del
manifiesto ágil en el contexto de los proyectos que utilizan la metodología
DAC. Se resaltan las prácticas más importantes.
Como primer valor se manifestó “valorar
más a los individuos y su interacción que a los procesos y las herramientas”.
Los procesos y herramientas deben ser una ayuda y guía para el equipo de
desarrollo pero es el equipo de desarrollo quien tiene el conocimiento, quien
desarrolla el software; por lo que tener
un equipo capacitado, disponible, con buenas relaciones y comprometido con el
proyecto es lo más importante.
En cuanto al tema de la documentación el
manifiesto dice “valorar más el software que funciona que la documentación exhaustiva”
sin embargo no afirma que no hagan falta los documentos. Este valor está más
enfocado a la comunicación en el proyecto la cual no debe ser mediante
documentos. La documentación debe ser
aquella que realmente le aporte valor al proyecto, que sirva para desarrollar y
no desarrollar para documentar. Este es el criterio de la autora al
respecto, siendo este uno de los elementos que muchos otros autores toman como
un problema de las metodologías ágiles.
La autora considera que el expediente del proyecto debe estar
correctamente estructurado, debe
regirse por un estándar o guía de configuración y debe tener definido el
carácter de cada documento. Esto quiere decir que existen documentos que deben
ser obligatorios dentro del proceso como el plan de desarrollo del software, la
especificación de requisitos, los documentos de arquitectura, las descripciones
de procesos, modelos de diseño y casos de prueba. Existen otros documentos o
herramientas que son de apoyo para lograr los productos de trabajo antes
mencionados y que no deben ser obligatorios. Cada proyecto debe definir cómo y
que usar para tener estos documentos obligatorios correctamente redactados y completos.
También existen los documentos que apoyan los procesos organizativos, de
gestión o soporte. Cada organización o
proyecto decide de acuerdo a sus características lo que es realmente necesario
para mantener una alta calidad en el proceso de desarrollo.
En cuanto a “valorar más la colaboración con
el cliente que la negociación contractual” la autora considera que
ambas cosas son importantes en los tiempos actuales, especialmente cuando se
hace un proyecto que implica gastos, recursos y que debe tener un beneficio. La colaboración y comunicación constante
con el cliente es y será siempre lo más importante, pues si esto falla el
proyecto también fallará. De la misma
forma es importante desde un inicio
dejar constancia de lo que el cliente pidió, en qué tiempo lo necesita, cuánto
dinero debe aportar al recibirlo. También es necesario que queden claras las responsabilidades por
ambas partes durante todo el proceso de desarrollo y como será efectuada la
comunicación. Suele suceder que el cliente al inicio pide algo y al no
firmarlo o llevarlo a un papel, no necesariamente un contrato pero si algo
oficial, al momento de la entrega o revisión de un prototipo, cambia de idea y
dice que eso no fue lo que quería en un inicio. El cliente por lo general tiene
mala memoria cuando se trata de lo que se acordó. Por eso es importante mantener siempre acuerdos firmados así como
actas de aceptación de aquello que se entrega. Es la forma que tienen las
partes de proteger sus intereses. En este sentido documentar las solicitudes de
cambio y monitorearlas hasta su cierre es muy importante.
El último valor del manifiesto ágil es “valorar
más la respuesta al cambio que el seguimiento de un plan”. En los
proyectos actuales los cambios ocurren incluso cuando hay contratos firmados y hay que estar preparados. Es aquí donde
la gestión de la configuración y cambios
juega un papel importante. Hay que saber
cómo atender una solicitud de cambio.
De igual forma el plan no puede ser
rígido, estático, debe ser flexible y estar en constante revisión. La
identificación temprana de los posibles
riesgos es una forma de estar preparados para el cambio. No obstante la
autora considera que siempre debe haber
un plan, la estimación es necesaria. Sin un plan no se sabe hacia dónde se
va, que falta, que se ha hecho. Es necesario saber identificar una desviación y saber cómo aplicar una acción correctiva. Un plan y responder ante
el cambio no son elementos aislados sino que tienen una fuerte relación. Sin
embargo planificar al detalle es
imposible en los contextos actuales y contrarresta la agilidad del
proyecto. La idea es hacer un plan
general, con una serie de hitos definidos, fechas estimadas, recursos, costos,
personal, etc. De forma mensual, quincenal o semanal como mínimo se
actualiza el plan y se detallan las tareas específicas de la semana, la
quincena o el mes. No planificar al
detalle más de un mes es una buena práctica para no emplear esfuerzo en vano.
De los cuatro valores se derivan los siguientes
principios tomados del manifiesto
ágil con los cuales la autora coincide considerándolos necesarios para
cualquier proceso de desarrollo en los tiempos actuales:
- Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
- Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo.
- Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
- Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
- Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
- Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
- La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
- El software que funciona es la principal medida del progreso.
- Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica enaltece la agilidad.
- La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
- En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
2. Prácticas para equipos ágiles
A
continuación se muestran un conjunto de prácticas que no han quedado
manifestadas de forma explícita en el modelo, los valores y principios del
manifiesto ágil:
- Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que
pueda ser satisfactoria para el cliente. Refactorización de código.
- Realizar reuniones de planificación
frecuentemente (frecuencia de pocas semanas, no meses). Planificar guiado por requisitos.
- Evitar adelantar
trabajo que no
esté comprometido y/o no esté cercano a su entrega.
- Gestión continua y multicriterio del
trabajo pendiente para que esté siempre debidamente priorizado (Tablero Kanban). Visualización de
todo el trabajo pendiente encargado al equipo.
- Formar equipos pequeños y procurar que
mantengan sus integrantes.
- Acotar el ámbito de trabajo del equipo. Especializar al equipo en un ámbito de
acción. Utilizar el KPT.
- Seguimiento continuo aprovechando la reunión diaria de no más de 15
minutos, cara a cara y muy breve. Establecer una disciplina de
aprovechamiento de las reuniones.
- Disponer de una herramienta de software que ofrezca soporte para gestionar de forma integrada el
proyecto.
- Cliente en estrecho contacto con el equipo y altamente disponible.
Satisfacer acuerdos con
involucrados.
- Que exista una única persona que tome las
decisiones respecto de las prioridades del trabajo del equipo y que sea un
buen representante de la parte cliente.
- Realizar reuniones de revisión del trabajo entregado. Revisiones de Hitos con el
equipo, el cliente y la alta gerencia.
- Establecer y comunicar al equipo la visión
del producto o servicio y reforzarla regularmente.
- Que los integrantes del equipo no tengan
solo algunas actividades fijas asignadas, que puedan encargarse de
diferentes tipos de actividades (ojalá de todas), aunque puedan ser
especialistas en alguna(s) de ellas.
- Que exista un líder de mejora de proceso disponible para el equipo.
- Establecimiento de estándares para el trabajo técnico del equipo. Estándar y documentación del código.
- Reuniones de retrospectiva para evaluar el desempeño del equipo y sus
formas de trabajo. Mejora Continua. Analizar los resultados.
- No trabajar más de 40 horas semanales.
- Reducir las interrupciones o cambios de
contexto que afectan en su trabajo a los miembros del equipo.
- Automatizar las
pruebas para
poder garantizar que el producto mantiene el comportamiento deseado cuando
se realizan cambios.
- Integrar de forma
continua en el
producto o servicio el trabajo terminado.
- Promover que los miembros del equipo en su
trabajo lleguen a conocer todas las partes del producto o servicio que han
sido encargadas al equipo.
- Mejorar
continuamente
la organización interna del producto para facilitar su mantenimiento.
- Aprovechar las tecnologías de las comunicaciones para la transmisión del
conocimiento y la comunicación del equipo.
- Colaboración
constante
entre los miembros del equipo. Socialización del conocimiento. Aprovechar
las herramientas como chats, fotos, internet, etc.
- Capacitación
constante del
equipo.
- Definición de una arquitectura de alto nivel desde el inicio de cada versión.
- Arquitectura y diseño basada en reutilización de componentes o
líneas de productos de software.
- Controlar las solicitudes de
cambio.
- Pruebas de liberación en cada iteración por componentes y entrega del
producto.
- Adaptar los procesos definidos.
- Seguir los procesos definidos.
- Entrenamiento formal sobre el dominio del sistema, los requisitos, procesos y tecnologías.
- Comunidad de prácticas que comparten información, conocimiento, experiencias, habilidades técnicas.
- Cada individuo debe prepararse de forma individual en aquellos aspectos que le interese profundizar o en los que tiene poco conocimiento.
- Wiki que contiene información relevante para el proyecto y conocimiento compartido.
- El sistema debe estar descrito en la documentación. También los procesos, las guías, los manuales, tutoriales, deben estar documentados y almacenados en un repositorio donde todo el equipo pueda acceder.
- Presentaciones técnicas es una forma de compartir buenas ideas o experticia técnica. Esta información debe ser interesante y memorable para la audiencia.
- Debates para facilitar una comunicación abierta entre los miembros del equipo. Provee oportunidades para refinar, volver a priorizar, generar requerimientos y soluciones.
Los procesos o fases del ciclo de vida del software
En el
proceso de desarrollo de software se ponen de manifiesto un grupo de
disciplinas que recaen en la categoría Ingeniería y se manifiestan en los
diferentes procesos del ciclo de vida del software. En la tabla 1 se muestra la
relación entre las disciplinas y los procesos del ciclo de vida.
Tabla 1 Relación entre las disciplinas
del proceso de desarrollo del software y los procesos del ciclo de vida del
producto en DAC.
Procesos
del Ciclo de Vida DAC
|
Disciplinas
relacionadas
|
Inicio del Proyecto
|
|
Análisis y Diseño de Alto Nivel
|
Modelado del Negocio
Arquitectura y Diseño
Especificación de Requisitos
|
Desarrollo de Requisitos
|
Arquitectura y Diseño
Especificación de Requisitos
|
Construcción del Producto
|
Arquitectura y Diseño
Implementación
Pruebas
|
Cierre de iteración
|
Pruebas
|
Liberación del Producto
|
Pruebas
|
Transición del producto
|
Despliegue
Mantenimiento
|
Cierre del Proyecto
|
1. Disciplinas de Ingeniería
1.1 Modelado del Negocio.
El modelado del negocio es una técnica
para comprender los procesos del negocio de la organización. Los
propósitos que se persiguen al realizarse el modelado del negocio, son:
- Entender
la estructura y la dinámica de la organización.
- Entender
los problemas actuales e identificar mejoras potenciales.
- Asegurarse
de que los clientes, usuarios finales y desarrolladores tienen una idea
común de la organización.
- Obtener
los requerimientos del sistema a partir del modelo de negocio que se obtenga
de las entrevistas y solicitudes del cliente.
En el Proceso de Análisis y Diseño de
Alto Nivel se realiza una primera aproximación del modelo de negocio. Es una
fuente fundamental de requisitos del software.
Productos de trabajo:
- Descripción de Procesos
de Negocio
- Modelo Conceptual
- Glosario de Términos
1.2 Arquitectura y Diseño.
En el proceso de Análisis y Diseño de
Alto Nivel mediante esta disciplina se llevan los requisitos solicitados a la
arquitectura que soportará el futuro sistema. Mediante un diseño de componentes
se tiene la idea de cómo funcionará el sistema, su composición y diseño visual.
Luego por cada componente en el proceso de Desarrollo de Requisitos se refina
la arquitectura y el diseño. Ya en la Construcción del Software se completan
los mismos a partir de cambios que surgen de necesidades de implementación para
que la arquitectura soporte todos los requisitos especificados.
En resumen se modela el sistema y se define la estructura
(incluida la arquitectura) para que soporte todos los requisitos, incluyendo
los requisitos no funcionales y otras restricciones. En concreto, los propósitos de esta disciplina son:
- Adquirir una comprensión en
profundidad de los aspectos relacionados con los requisitos no funcionales
y restricciones relacionadas con los lenguajes de programación,
componentes reutilizables, sistemas operativos, tecnologías de
distribución y concurrencia, tecnologías de interfaz de usuario,
tecnologías de gestión de transacciones, etc.
- Crear una entrada apropiada y
un punto de partida para actividades de implementación subsiguientes
capturando los requisitos o subsistemas individuales, interfaces y clases.
- Ser capaces de descomponer los
trabajos de implementación en partes más manejables que puedan ser
llevadas a cabo por diferentes equipos de desarrollo, teniendo en cuenta
la posible concurrencia.
- Capturar las interfaces entre
los subsistemas antes en el ciclo de vida del software. Esto ayuda cuando se
reflexiona sobre la arquitectura y cuando se utilizan interfaces como
elementos de sincronización entre diferentes equipos de desarrollo.
- Ser capaces de visualizar y
reflexionar sobre el diseño utilizando una notación común.
- Crear una abstracción sin
costuras de la implementación del sistema, en el sentido de que la
implementación es un refinamiento directo del diseño que rellena lo
existente sin cambiar la estructura. Esto permite la utilización de
tecnologías como la generación de código y la ingeniería de ida y vuelta
entre el diseño y la implementación.
- Definir las pautas de diseño
para las interfaces de usuario y la arquitectura de información.
- Proporcionar la organización de
la información y los requisitos en el sistema potenciando la usabilidad
del mismo.
Productos de trabajo:
- Arquitectura de
Software Guía Base
- Vista de Arquitectura
de Sistema
- Vista de Arquitectura
de Datos
- Vista de Arquitectura
de Presentación
- Vista de Arquitectura
de Tecnología e Infraestructura
- Modelo de diseño
(Llevar además los modelos en una herramienta CASE)
1.3 Especificación de Requisitos.
Define qué es lo que el sistema debe
hacer a partir del listado original de requisitos levantado con el cliente en
el inicio del proyecto, durante el modelado de negocio y la arquitectura y
diseño. Para esto se identifican requisitos derivados, se determinan todos los
requisitos no funcionales a partir de la arquitectura definida, se validan,
priorizan y evalúan los requisitos y finalmente se especifican mediante
escenarios, prototipos y storyboard. Los principales objetivos de esta
disciplina son:
- Definir
los límites (alcance) del sistema.
- Proporcionar
al cliente un entendimiento común de los requisitos del software mediante
descripciones en lenguaje natural y prototipos.
- Proporcionar
a los desarrolladores del sistema una descripción detallada de los
requisitos del sistema mediante escenarios, prototipos, storyboarding y
otras técnicas de especificación.
- Proporcionar
a los probadores un conjunto de casos de prueba basados en las
especificaciones de requisitos para obtener la mayor cantidad de defectos
posibles en el software y poder solventarlos correctamente en la
disciplina de pruebas.
Los requerimientos son la pieza
fundamental en un proyecto de desarrollo de software, en ellos se basan los
participantes del proyecto para:
- Planear
el proyecto y los recursos que se emplearán en él
- Especificar
los tipos de pruebas que se habrán de realizar al sistema.
- Son
el fundamento del ciclo de vida del proyecto.
Productos de trabajo:
- Catálogo de Requisitos
- Especificación de
Requisitos de Software (Llevar los prototipos además en una herramienta de
prototipado)
- Descripción
Detallada del Requisito
1.4 Implementación.
Esta disciplina se encarga de convertir
las especificaciones de los requisitos del software en código ejecutable en la
tecnología de programación seleccionada. También de implementar los componentes
de arquitectura definidos y los patrones e interfaces necesarios para su
integración. Define cómo se organizan las clases y objetos en componentes,
cuáles nodos se utilizarán y la ubicación en ellos de los componentes y la
estructura de capas de la aplicación.
El objetivo principal de la
implementación es desarrollar la arquitectura y el sistema como un todo. De
forma más específica, los propósitos de la Implementación son:
- Definir
la organización del código.
- Planificar
las integraciones de sistema necesarias en cada iteración.
- Implementar
las clases y subsistemas encontrados necesarios para cumplir la
especificación del requisito.
- Manejar
y administrar la base de datos durante la implementación.
Productos de trabajo:
- Script de base de datos
- Código Fuente
- Ayuda Interna del
Software (opcional)
- Ejecutable o Instalador
(opcional)
1.5 Pruebas
En ella se establece como objetivo buscar
los defectos a los largo del ciclo de vida del producto. Se hacen distintos
tipos de pruebas. Unitarias durante la implementación y durante la liberación
del producto ya sea de caja negra realizada por analistas o caja blanca por los
desarrolladores. También pruebas de
integración al concluir cada componente y pruebas de liberación para revisar
que se cumplan los requisitos funcionales y no funcionales, ejecutadas
preferentemente por probadores externos al proyecto. Otro tipo de pruebas
importantes son las pruebas piloto y de aceptación durante la Transición del Producto.
La prueba del software es un elemento
crítico para la garantía de la calidad del software. El objetivo de la
disciplina de pruebas es garantizar la calidad del producto desarrollado.
Además implica:
- Verificar
la interacción de componentes.
- Verificar
la integración adecuada de los componentes.
- Verificar
que todos los requisitos se han implementado correctamente.
- Identificar
y asegurar que los defectos encontrados se han corregido antes de entregar
el software al cliente.
- Diseñar
pruebas que sistemáticamente saquen a la luz diferentes clases de errores,
haciéndolo con la menor cantidad de tiempo y esfuerzo.
- Buscar
formas de automatización de las pruebas como técnica de desarrollo ágil.
Productos de trabajo:
- Diseño de Casos de
Prueba
- Registro de No
Conformidades
1.6 Despliegue.
Produce una liberación del producto y en
ella se realizan actividades de empaque, instalación, asistencia a usuarios,
etc., para entregar el software a los usuarios finales. Además aquí es donde se
realiza la migración del software o datos existentes.
El Despliegue describe las actividades
que hay que realizar para asegurar que el producto de software desarrollado se
puede utilizar por los usuarios finales. Además, hay que considerar:
- Empaquetar
el software.
- Distribuir
el software.
- Instalar
el software.
- Ofrecer
ayuda, capacitación y asistencia a los usuarios.
- Migración
de datos existentes
Productos de trabajo:
- Manual de Usuario
- Estrategia de
capacitación
- Programas de cursos de
capacitación
1.7 Mantenimiento del Software
Disciplina dedicada
a mantener y mejorar el software para corregir errores descubiertos e
incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el
desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida
de un proyecto está dedicado a su mantenimiento. Una pequeña parte de este
trabajo consiste eliminar errores (bugs y la mayor parte reside en extender el
sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.
A continuación se señalan los tipos
servicio de mantenimientos existentes, y entre paréntesis el porcentaje aproximado
respecto al total de operaciones de mantenimiento:
- Perfectivo (60%): Mejora del software (rendimiento, flexibilidad, reusabilidad) o implementación de nuevos requisitos. También se conoce como mantenimiento evolutivo.
- Adaptativo (18%): Adaptación del software a cambios en su entorno tecnológico (nuevo hardware, otro sistema de gestión de bases de datos, otro sistema operativo, etc.)
- Correctivo (17%): Corrección de fallos detectados durante la explotación.
- Preventivo (5%): Facilitar el mantenimiento futuro del sistema (verificar precondiciones, mejorar legibilidad).
Durante el proceso de Cierre de Iteración
mediante la refactorización de código se hace el mantenimiento preventivo del
software. Luego en el proceso de Transición es donde tienen todos los tipos de
mantenimiento en dependencia de las solicitudes de servicio del cliente,
usuarios o el propio proyecto. Suele hacerse mientras se desarrollan otras
versiones del mismo producto antes del cierre del proyecto o por un tiempo
definido luego de cerrar el proyecto como una nueva etapa del software. En este
caso debe tratarse el mantenimiento como un proceso diferente al ciclo de vida
del software definido aquí.
Para el mantenimiento se lleva otro
expediente de proyecto una vez haya finalizado el mismo.
Fases o procesos del ciclo de vida
P1 Proceso de Inicio del Proyecto
Durante el inicio del proyecto se llevan
a cabo las actividades relacionadas con la evaluación de la factibilidad del
proyecto, la planeación del proyecto a un alto nivel y el registro de este. En
esta fase se realiza un estudio inicial de la organización cliente que permite
obtener información fundamental acerca del alcance del proyecto, realizar
estimaciones de tiempo, esfuerzo y costo, y decidir si se ejecuta o no el
proyecto. Se obtienen los requisitos de alto nivel traducidos en objetivos y se
establecen los primeros acuerdos con proveedores y clientes de ser necesario.
Los objetivos
de este proceso son:
- Asegurar
la factibilidad del proyecto.
- Establecer
un plan general para la ejecución del proyecto.
Hitos:
- Concluir
el estudio de factibilidad.
- Firmar suplemento de contrato o acuerdo de colaboración.
- Alistar el entorno de ejecución del proyecto para la siguiente etapa.
P2 Proceso de Análisis y Diseño de Alto Nivel
Durante este proceso se modelan los
procesos de negocio o se hace una conceptualización del problema para cada
entrega planificada. A partir de los requisitos de alto nivel se diseña una
arquitectura sólida que se convierte en un plano para el desarrollo de las
iteraciones. Debe quedar definida la estructuración por paquetes y componentes
de la arquitectura, la priorización de los requisitos de alto nivel, el entorno
de desarrollo, la arquitectura de datos, seguridad, integración, presentación y
despliegue a grandes rasgos. Se podrán realizar actualizaciones de las vistas
de arquitectura durante el desarrollo de las iteraciones incluyendo el ajuste
de los planes del proyecto. En caso de ser necesario se construirán los
componentes de apoyo necesarios y el marco de trabajo para la ejecución de las
iteraciones del proyecto. Se deben refinar los requisitos de alto nivel y
obtenerse los requisitos funcionales y no funcionales del software. Los
requisitos deben ser validados con el cliente.
El objetivo
de este proceso es:
·
Obtener una arquitectura base que satisfaga los
requisitos.
Hitos:
- Definir y Evaluar la arquitectura de software para la entrega.
- Aceptación de los requisitos de software para la entrega.
P3 Proceso de Desarrollo de Requisitos
Es la etapa destinada primeramente a realizar el diseño
detallado del componente que se desarrolla. Se estudia cómo funciona el negocio
que se desea informatizar/automatizar. El esfuerzo principal en la etapa es
obtener la descripción de los requisitos del componente que se va a obtener en
la iteración y sus correspondientes diseños de casos de prueba. Incluye un
conjunto de artefactos que describen todas las interacciones que tendrán los
usuarios con el software y que responden a los requisitos funcionales del sistema.
Durante esta etapa es modelado el sistema para que soporte todos los requisitos
de la iteración actualizando la arquitectura del software en caso de ser
necesario.
El objetivo
de este proceso es:
·
Obtener una descripción de requisitos que pueda
ser implementada y probada.
Hitos:
- Realizar
el análisis y diseño del componente.
- Descripción
detallada de los requisitos funcionales del componente.
P4 Proceso de Construcción del Software
A partir la descripción de la arquitectura y los
requisitos se implementa el sistema en términos de componentes, es decir,
ficheros de código fuente, scripts, ejecutables y similares. Al reutilizar
componentes software ya implementados se lleva a cabo el desarrollo necesario
para ajustar a los requisitos actuales y posteriormente realizar la integración
de los componentes. Se crea la base de datos a partir del diseño realizado. Se
crea la estructura del componte en agrupaciones funcionales y se analizan los
patrones de diseño definidos en la arquitectura buscando la forma más óptima de
implementar los requisitos especificados. En esta etapa cuando el diseño está
completo se concluye la construcción del componente previsto para la iteración.
El objetivo
de este proceso es:
·
Obtener un componente que cumpla con el diseño
y las descripciones de requisitos definidas.
Hitos:
- Concluir el desarrollo
del componente.
P5 Proceso de Cierre de Iteración
Durante esta fase se desarrollan las pruebas internas a los
componentes desarrollados verificando el resultado de la implementación y la
satisfacción de los requisitos del software. Permite identificar posibles
errores en la documentación y el software, es decir requisitos que el producto
debería cumplir y que aún no los cumple y corregirlos. También si así lo decide
el jefe del proyecto, el director del proyecto, la alta gerencia o el cliente
se pueden realizar las actividades de la fase Liberación y Transición aplicadas
solamente para el componente o grupo de componentes desarrollados hasta el
momento con el fin de realizar pruebas piloto. También se analizan las
lecciones aprendidas y se toman decisiones críticas sobre el avance del
proyecto, se realizan algunas actividades eventuales y periódicas de las áreas
de procesos de Gestión de Proyecto y Soporte. Se realiza el análisis de
resultados y se revisa si hay necesidades de adquisición y se realizan las
solicitudes de oferta de productos o servicios para proveedores identificados.
El objetivo
de este proceso es:
·
Garantizar que el componente satisface las
necesidades de los clientes y usuarios finales.
·
Analizar lecciones aprendidas para la
planificación de próximas iteraciones y versiones del producto.
Hitos:
- Validar la integración
del componente desarrollado al resto del producto.
- Validar la
funcionalidad del componente.
- Análisis de los
resultados del proyecto.
P6 Proceso de Liberación del Producto
Durante esta fase se aplican pruebas
diseñadas e implementadas por el grupo de control de la calidad que liberará al
software y a todos los entregables del proyecto al cliente para su aceptación.
El objetivo
de este proceso es:
·
Lograr que el producto final sea liberado por
el grupo de control de la calidad.
Hitos:
- Productos de trabajo
liberados.
P7 Proceso de Transición del Producto
Durante
esta etapa se procede a la entrega de la versión del producto, así como a la
instalación, configuración, prueba y puesta en marcha del software en el
entorno real del cliente. Las pruebas de esta etapa incluyen pruebas de
aceptación y pruebas pilotos, preferiblemente de tipo Alfa y Beta
respectivamente. También deben realizarse en este período la capacitación y
acompañamiento a usuarios para asegurar que adquieran los conocimientos
necesarios en la manipulación del software. Durante esta etapa el
producto es transferido al ambiente de los usuarios finales o entregado al
cliente.
El objetivo
de este proceso es:
·
Desplegar el producto en un ambiente
operacional.
·
Capacitar a los usuarios e involucrados con el
producto de software.
Hitos:
- Aceptación del
producto por el cliente.
- Concluir la transición
de la versión del producto al entorno del cliente.
P8 Proceso de Cierre del Proyecto
En esta
fase se analizan tanto los resultados del proyecto como su ejecución y se
realizan las actividades formales de cierre del proyecto. Solamente se llega a
ejecutar esta fase cuando se han desarrollado todas las versiones del producto
pactadas.
El objetivo
de este proceso es:
·
Analizar los resultados y experiencias del
proyecto.
·
Cerrar formalmente el proyecto.
Hitos:
- Realizar evaluación de cierre del Proyecto.
- Concluir legal y financieramente el proyecto.
Áreas de procesos de protección o apoyo
Las áreas de proceso de
protección abarcan todas las actividades de apoyo al proceso de desarrollo del
software. En las mismas se desarrollan las áreas de proceso de CMMI. Debido a
que en AICROS se pretenden alcanzar las metas genéricas y específicas para el
segundo nivel de madurez cada área de proceso se corresponde con su
correspondiente categoría CMMI.
1. Área de procesos de protección Gestión de Proyectos
En esta área de procesos de protección se
concentran actividades de planeación general del proyecto, monitoreo y control,
administración de acuerdos con proveedores, reuniones y reportes de estado.
Aunque algunas actividades no aparezcan como parte del ciclo de vida del
software no significa que no sean planificadas. Abarca los siguientes procesos:
- Proceso de Gestión de Requisitos
- Proceso de Planificación del Proyecto
- Proceso de Gestión de Acuerdos con Proveedores
- Proceso de Monitoreo y Control del Proyecto
Productos de trabajo:
- Solicitud de proyecto
- Contratos
- Método de estimación
inicial y post-arquitectura
- Estudio de Factibilidad
- Oferta
- Acta de Inicio del
Proyecto
- Plan de Desarrollo de
Software
- Plan de Pruebas
- Registro de Monitoreo
(opcional)
- Registro de Revisiones
de Inconsistencia (opcional)
- Herramienta de
trazabilidad
- Acta de Cierre del
Proyecto
- Minutas de reunión
- Actas de aceptación
- Reportes e Informes de resultados (opcional)
2. Área de procesos de protección Soporte
En esta área de procesos de protección se
concentran actividades de soporte en general, gestión del conocimiento,
administración de la calidad y administración de la configuración. Aunque
algunas actividades no aparezcan como parte del ciclo de vida del software no
significa que no sean planificadas. Abarca los siguientes procesos:
- Proceso de Gestión de la Configuración
- Proceso de Medición y Análisis
- Proceso de Aseguramiento de la Calidad del Proceso y el Producto
Productos de trabajo:
- Solicitud de cambio
- Lista de verificación
de la configuración (opcional)
- Registro de
evaluaciones del proyecto
- Reportes e Informes de resultados (opcional)
WBS del Proyecto
Un Work Breakdown
Structure o WBS, también conocida por su nombre en español Estructura de
Descomposición del Trabajo o EDT, es en gestión de proyectos una descomposición
jerárquica orientada al entregable, del trabajo a ser ejecutado por el equipo
de proyecto, para cumplir con los objetivos de éste y crear los entregables
requeridos, con cada nivel descendente del WBS representando una definición con
un detalle incrementado del trabajo del proyecto. El WBS es una herramienta
fundamental en la gestión de proyectos. El propósito de un WBS es organizar y
definir el alcance total aprobado del proyecto según lo declarado en la
documentación vigente. Su forma jerárquica permite una fácil identificación de
los elementos finales, llamados "Paquetes de Trabajo". Se trata de un
elemento exhaustivo en cuanto al alcance del proyecto, el WBS sirve como la
base para la planificación del proyecto. Todo trabajo a ser hecho en el
proyecto debe poder rastrear su origen en una o más entradas del WBS.
El WBS tiene las
siguientes funcionalidades:
- Define el flujo del Sistema del Proyecto y el éxito del mismo al 100%
- Organiza el flujo del trabajo.
- Asegura que no se dupliquen las tareas.
- Controla el Avance del Trabajo.
- A partir de los entregables graficados
aquí se puede determinar cuándo y quien los realizara (Cronograma)
El último nivel, Paquete
de Trabajo, engloba todo el conjunto de tareas que se verán reflejadas en el
Cronograma. A partir de la Definición del Alcance se construye WBS. El WBS
determina el “QUE” del cual sale el Cronograma que determina el “Cuando” y el
“Quien”. Se definen sus primeros niveles al inicio del proyecto pero se
completa al finalizar el proceso de Análisis y Diseño Arquitectónico. Luego
durante la ejecución se realizan los controles respetivos. Si surgen cambios se
debe actualizar la línea base del WBS. Por último se actualiza el Cronograma.
En el WBS se ponen entregables no tareas. La suma de los paquetes de trabajo
debería ser el 100% del alcance del proyecto en todos los niveles. Nuevos
entregables no pueden ser añadidos al WBS sin una solicitud de cambio.
Se debe crear tantos
niveles como se requieran. Se recomienda no exceder de 7 ramas por nivel. Los
paquetes de trabajo deben ser exclusivos para no causar ambigüedad y duplicar
el trabajo. Si se tienen demasiadas tareas para un entregable puede significar
que el WBS se estancó en un nivel equivocado. Por otro lado no se debe descender
demasiado en los niveles porque haría lento el avance del Proyecto. Los
paquetes de trabajo deben estar conformados por más de 1 actividad caso
contrario se ha llegado a demasiado detalle en ese nivel.
Ventajas:
- Mejora la comprensión del trabajo a realizar
- Se minimiza las omisiones.
- Facilita la identificación de las Tareas Globales.
- Mejora la forma de asignación de responsabilidades.
- Es una buena herramienta de comunicación
- Facilita la construcción de los Cronogramas.
En las Fig. 4 y Fig. 5 se
muestra el WBS clásico de la metodología DAC.
Fig. 4 WBS ejemplo del producto
que se obtiene aplicando la metodología DAC.
Fig. 5 WBS de ejemplo en el
nivel de Iteración utilizando la metodología DAC.
No hay comentarios:
Publicar un comentario
Por fa déjame un comentario