B4lvre1596217837

ANÁLISIS Y GESTIÓN DE REQUERIMIENTOS Y REQUISITOS DE LA
SOLUCIÓN DE SOFTWARE PARA APOYAR EL PROCESO DE GESTIÓN DE
NÓMINA EN LA UNIVERSIDAD DISTRITAL, SIGUIENDO LOS LINEAMIENTOS
DEL PROCESO DE DESARROLLO OPENUP/OAS EN SUS FASES DE INICIO,
ELABORACIÓN Y CONSTRUCCIÓN.
AUTOR:
SERGIO DAVID ORJUELA VELÁSQUEZ
PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE
SISTEMAS
ALEJANDRO PAOLO DAZA
DIRECTOR
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2015

TABLA DE CONTENIDO
CAPÍTULO 1. INTRODUCCIÓN................................................................................6
CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA................................................7
CAPÍTULO 3. OBJETIVOS........................................................................................9
3.1. Objetivo General.............................................................................................9
3.2. Objetivos Específicos......................................................................................9
CAPÍTULO 4. JUSTIFICACIÓN...............................................................................10
CAPÍTULO 5. MARCO TEÓRICO...........................................................................11
5.1. El Proceso OPENUP/OAS............................................................................11
5.1.1. Generalidades........................................................................................11
5.1.2. El método de trabajo..............................................................................14
5.1.3. Subprocesos OPENUP/OAS..................................................................18
5.2. Ingeniería de Requerimientos y Requisitos..................................................21
5.2.1. Generalidades........................................................................................21
5.2.2. Gestión de requerimientos y requisitos..................................................21
5.2.3. Los requerimientos y requisitos..............................................................22
5.2.4. ¿Cómo detallar un requerimiento?.........................................................23
5.2.5. Definición de requisitos..........................................................................24
5.2.6. Técnicas de capturas de requerimientos...............................................24
5.2.7. Casos de Uso.........................................................................................25
5.3. La Nómina: estructura, partes y elementos básicos.....................................26
5.3.1. Retribución bruta: conceptos que conforman el salario bruto...............27
5.3.2. Descuentos en la nómina.......................................................................28
5.3.3. Procesos de liquidación para docentes de vinculación especial en la
Universidad Distrital..........................................................................................28
5.3.4. Procesos de liquidación para contratistas en la Universidad Distrital...32
CAPÍTULO 6. METODOLOGÍA...............................................................................35
CAPÍTULO 7. DESARROLLO.................................................................................40
7.1. Modelo De Gestión De Nómina....................................................................43
2

7.2. Modelo BPMN - Gestión De Nómina............................................................44
7.3. Requerimientos No Funcionales...................................................................52
7.4. Requerimientos Funcionales Identificados...................................................54
7.5. Sistema De Gestión De Nómina (TITAN-Descripción por Módulo)..............64
7.5.1. Módulo: Parámetros Del Sistema...........................................................65
7.5.2. Módulo: Gestión Persona.......................................................................70
7.5.3. Módulo: Gestión Conceptos...................................................................72
7.5.4. Módulo: Gestión De Novedades............................................................78
7.5.5. Módulo: Gestión De Liquidación............................................................87
7.5.6. Módulo: Gestión De Reportes................................................................90
CAPITULO 8. RESULTADOS Y TRABAJO A FUTURO..........................................92
CAPITULO 9. CONCLUSIONES.............................................................................93
CAPÍTULO 10. BIBLIOGRAFÍA...............................................................................95
ANEXOS..................................................................................................................97
Especificaciones De Caso De Uso:.....................................................................97
3

ÍNDICE DE ILUSTRACIONES
Ilustración 1 Mapa de Subprocesos OPENUP/OAS...............................................18
Ilustración 2 Equipo de Desarrollo del Proceso OPENUP/OAS.............................20
Ilustración 3 Metodología de Trabajo......................................................................38
Ilustración 4 Metodología Subproceso de "Gestión de Requerimientos y
Requisitos"...............................................................................................................39
Ilustración 5 Flujo de Trabajo Proyecto TITAN........................................................41
Ilustración 6 Artefacto Plan General de Ejecución del Proyecto.............................42
Ilustración 7 Artefacto de Control de Cambios........................................................42
Ilustración 8 Modelo de Dominio.............................................................................44
Ilustración 9 Diagrama BPM (Gestión Persona).....................................................45
Ilustración 10 Diagrama BPM (Gestión Vinculación Persona Natural)...................46
Ilustración 11 Diagrama BPM (Gestión de Parámetros).........................................47
Ilustración 12 Diagrama BPM (Gestión de Conceptos)...........................................47
Ilustración 13 Diagrama BPM (Gestión de Novedades 1)......................................48
Ilustración 14 Diagrama BPM (Gestión de Novedades 2)......................................49
Ilustración 15 Diagrama BPM (Pre liquidación).......................................................50
Ilustración 16 Diagrama BPM (Liquidación)............................................................51
Ilustración 17 Diagrama BPM (Gestión de Plantilla)...............................................51
Ilustración 18 Diagrama BPM (Gestión de Plantilla)...............................................52
Ilustración 19 Diagrama de Caso Uso (Parámetro Actividades Económicas)........66
Ilustración 20 Diagrama de Caso Uso (Parámetro Fondo de Pensiones)..............67
Ilustración 21 Diagrama de Caso Uso (Parámetro Tipo de Vinculación)................68
Ilustración 22 Diagrama de Caso Uso (Parámetro de Liquidación)........................69
Ilustración 23 Diagrama de Caso Uso (Gestión de Categorías de Parámetros de
Liquidación)..............................................................................................................70
Ilustración 24 Diagrama de Caso Uso (Gestión Persona)......................................71
Ilustración 25 Fases de Registro y Modificación de un Concepto..........................73
Ilustración 26 Diagrama de Caso Uso (Registro de Concepto)..............................73
Ilustración 27 Diagrama de Caso Uso (Actualización de Concepto)......................74
Ilustración 28 Diagrama de Caso Uso (Inactivación y Consulta de Concepto)......75
Ilustración 29 Diagrama de Caso Uso (Gestión Categorías de Conceptos)...........76
Ilustración 30 Diagrama de Caso Uso (Gestión de Asociación de Conceptos)......78
Ilustración 31 Fases de Registro y Modificación de Novedad................................80
Ilustración 32 Diagrama de Caso Uso (Generar Novedad)....................................80
Ilustración 33 Diagrama de Caso Uso (Editar Novedad)........................................81
Ilustración 34 Diagrama de Caso Uso (Consultar e Inactivar Novedad)................82
Ilustración 35 Diagrama de Caso Uso (Asociar Novedad a Empleado).................83
4

Ilustración 36 Diagrama de Caso Uso (Modificar Novedad Asociada)...................84
Ilustración 37 Diagrama de Caso Uso (Consultar e Inactivar Novedad Asociada).84
Ilustración 38 Diagrama de Caso Uso (Vinculación Persona Natural)....................86
Ilustración 39 Diagrama de Caso Uso (Registro y Gestión de Hoja de Vida).........87
Ilustración 40 Diagrama de Caso Uso (Gestión de Nómina)..................................88
Ilustración 41 Diagrama de Caso Uso (Gestión de Pre liquidaciones)...................89
Ilustración 42 Diagrama de Caso Uso (Gestión Liquidaciones)..............................90
ÍNDICE DE TABLAS
Tabla 1 Actividades y Tareas Fase de Inicio............................................................14
Tabla 2 Actividades y Tareas Fase de Elaboración.................................................16
Tabla 3 Subproceso de “Gestión de Requerimientos y Requisitos” del Proceso de
Desarrollo OPENUP/OAS........................................................................................19
Tabla 4 Roles del Proceso OPENUP/OAS..............................................................20
Tabla 5 Factor Categoría Docentes de Vinculación Especial.................................30
Tabla 6 Tabla de Descuentos Docentes de Vinculación Especial...........................30
Tabla 7 Tabla de Impuestos.....................................................................................31
Tabla 8 Honorarios Mensuales................................................................................32
Tabla 9 Impuestos y Descuentos Contratistas........................................................33
Tabla 10 Requerimientos No Funcionales del Sistema...........................................53
Tabla 11 Listado Maestro de Requerimientos Funcionales....................................55
5

CAPÍTULO 1. INTRODUCCIÓN
La Universidad Distrital Francisco José de Caldas es un ente autónomo de
Educación Superior cuya misión se centra en las funciones básicas de docencia,
investigación y extensión. Para poder desempeñar su labor como institución
académica y pública requiere de la vinculación de personas naturales y jurídicas
(contratistas, docentes de planta, docentes de vinculación especial,
administrativos, etc.) quienes a través de sus habilidades y talentos apoyan el
desarrollo de todas las actividades que la Universidad debe llevar a cabo; dichas
vinculaciones implican el cumplimiento de un conjunto de requisitos legales, entre
los cuales destaca la nómina, la cual hace referencia a la retribución monetaria
que se ofrece a una organización o persona por sus servicios.
Sin importar el tipo de vinculación contractual que una persona natural tenga con
la Universidad, se debe realizar periódicamente una gestión de nómina, proceso
en el cual se liquidan los honorarios, prestaciones y aportes patronales, seguridad
social, parafiscales y prestaciones sociales según sea el caso y de acuerdo a las
consideración establecidas por la ley.
Actualmente la Institución cuenta con un proceso de gestión de nómina que se
condiciona y se altera de acuerdo al tipo de vinculación contractual existente. En
consecuencia, la Universidad cuenta con algunas herramientas informáticas que
soportan dichos procesos, que van desde hojas de cálculos de Excel hasta
soluciones más robustas soportadas en bases de datos Oracle. Sin embargo el
común denominador de estos procesos es la baja flexibilidad a nuevos
requerimientos legales o tributarios del entorno externo o institucional, así como la
baja interoperabilidad con otros componentes de software requeridos para
efectuar los pagos y causaciones financieras.
Teniendo en cuenta lo anterior, la Oficina Asesora de Sistemas (OAS) de la
institución tiene como proyecto analizar, diseñar y construir una solución de
software integral y escalable que permita apoyar los procesos relacionados a la
gestión de nóminas. Con este fin, el proyecto que se describe a lo largo de este
documento (gestión y análisis de requerimientos) hace parte del proyecto
propuesto por la OAS que busca solucionar los problemas planteados.
6

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA
La Universidad Distrital debe realizar periódicamente la gestión de nómina de
todas las personas vinculadas a la institución, pero las herramientas informáticas
que se utilizan actualmente son obsoletas para soportar la información y los
procesos que la liquidación de nómina implica.
Esto, sumado a la poca interoperabilidad de las herramientas con otros
componentes de software a nivel interno y externo genera poca confianza, la
escaza disponibilidad e integridad de los datos, las demoras en los pagos de
honorarios o sueldos, los traumatismos en los procesos internos de la división de
recursos financieros y recursos humanos, la revelación inadecuada y poco
fidedigna de la información financiera y la falta de información oportuna para la
presentación de informes a los diferentes entes de control convergen en
resultados incompletos, no confiables y que no soportan adecuadamente los
procesos involucrados en la nómina, en consecuencia con lo anteriormente
nombrado los procesos dentro de la institución en lo que a gestión nomina
respecta no son óptimos.
Adicionalmente, dentro de la institución existen diferentes tipos de vinculación
(como los profesores de planta, profesores de vinculación especial, contratistas,
administrativos y pensionados) que se someten a procesos de liquidación de
nómina diferentes, por lo que la gestión de nómina en la Universidad Distrital es
una tarea compleja que implica más que un simple software ofimático o de baja
adaptabilidad. Lo anteriormente mencionado hace evidente la falta de cohesión y
el aislamiento de los procesos de gestión de nómina de acuerdo a los diferentes
tipos de vinculación.
Por ejemplo, los procesos relacionados a la nómina de los docentes de vinculación
especial y los contratistas son críticos, debido al tratamiento especial que se debe
aplicar en cado uno de los casos, razón por lo cual es necesario el análisis y la
identificación de los procedimientos de gestión de nómina particulares de estos
dos tipos de vinculación. Otro de los factores a tener en cuenta es la hoja de vida
como una de las unidades fundamentales de la vinculación y gestión de nómina
para la cual también se hace necesario la generación de un meta modelo de hoja
de vida que se pueda generalizar en todas las vinculación existentes.
7

CAPÍTULO 3. OBJETIVOS
3.1. Objetivo General
Realizar el análisis y la gestión de requerimientos y requisitos de una solución
modular, integral y escalable que permita apoyar los procesos relacionados a la
gestión de nóminas de la Universidad Distrital, soportado en tecnologías libres,
siguiendo el proceso de desarrollo OPENUP/OAS.
3.2. Objetivos Específicos
● Caracterizar el modelo de operación del sistema con el fin de definir los
requerimientos funcionales y no funcionales que deben considerarse en la
solución de software.
● Comprender las interacciones entre los usuarios y el sistema a desarrollar
partiendo de los requerimientos y los diálogos con los interesados, con el
fin de aclarar el conjunto de casos de uso requeridos en la solución al
problema planteado.
● Generar los artefactos establecidos por el proceso de desarrollo
OPENUP/OAS en el subproceso de “Gestión de Requerimientos y
Requisitos”, que serán base del proceso de desarrollo.
● Realizar los modelos gráficos de los procesos involucrados en la gestión
de nóminas en las Universidad Distrital utilizando notación estandarizada y
notación de procesos BPMN.
9

CAPÍTULO 4. JUSTIFICACIÓN
Debido a que la Universidad Distrital no cuenta con un sistema integral, unificado y
escalable que permita soportar el proceso de gestión de nómina en la Institución
de las personas naturales que tiene algún vínculo contractual con la Universidad,
se hace necesario el análisis, diseño y desarrollo de una solución de software.
Esto permite unificar los diferentes tipos de nóminas existentes en un solo
sistemas de información web, cuyas características sea una alta interoperabilidad
con otros componentes de software, adaptable a los cambios normativos y legales
del entorno interno o externo y que cumpla requisitos de alta calidad en
capacidades de usabilidad, fiabilidad, rendimiento y mantenimiento del software.
Aunque la Universidad Distrital es formadora de profesionales de alta calidad,
reconocidos en el entorno laboral por su buen desempeño en los campos donde
aplican sus saberes, en últimos años el trabajo conjunto entre los futuros
profesionales y la institución ha decaído.
Debido a esto, la Oficina Asesora de Sistemas tiene como objetivo vincular a los
estudiantes de últimos semestres de ingeniería de sistemas al desarrollo de los
proyectos vigentes, proceso que afianzará y fortalecerá los conocimientos y las
habilidades de los futuros profesionales y permitirá que estos últimos aporten a
través de sus competencias al crecimiento de la institución superior.
El desarrollo a través del trabajo conjunto de los estudiantes y la Oficina Asesora
de Sistemas de la Universidad de una solución integral de software permitirá
reducir el tiempo invertido en el proceso de la liquidación de la nómina en
cualquier tipo de vinculación contractual en la Universidad y consecuentemente
pagos oportunos a los funcionarios, docentes y contratistas de la Institución.
Por otro lado, por ser un sistema interoperable permitirá lograr una sincronización
precisa de datos con otros sistemas proveedores o destinatarios y armonizar la
información organizacional.
10

CAPÍTULO 5. MARCO TEÓRICO
5.1. El Proceso OPENUP/OAS.
En el marco de la resolución 461 de Rectoría del 29 de Julio de 20111
, la
Universidad Distrital Francisco José de Caldas avaló el método de desarrollo
OPENUP/OAS, como el marco de trabajo institucional en el análisis, diseño,
desarrollo e implementación de productos de software al interior de la Universidad.
A continuación se describen sus principales directrices y fundamentos.
5.1.1. Generalidades
El proceso OPENUP/OAS es un método de trabajo que involucra un conjunto
mínimo de prácticas tendientes a guiar a un equipo de trabajo pequeño en el
análisis, diseño, desarrollo y despliegue de un producto de software. Los objetivos
que persigue son:
● Promover la colaboración y compartir conocimientos alineando intereses
del equipo de trabajo y los usuarios.
● Ayudar al equipo a enfocarse en la arquitectura de forma rápida, de tal
manera que se minimicen los riesgos y se organice el desarrollo.
● Ayudar al equipo a balancear prioridades en conflicto para maximizar el
valor obtenido por los interesados en el proyecto.
● Ayudar al equipo en la evolución continua del producto para obtener
retroalimentación constante y fomentar el mejoramiento.
● Permitir a los administradores del proyecto realizar seguimientos a los
avances basados en metas e indicadores.
● Permitir que los integrantes del equipo entiendan rápidamente como
realizar el trabajo para alcanzar los objetivos y metas proyectadas.
1COLOMBIA. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS.
Resolución No 461. (29, Julio, 2011). Por medio de la cual se adopta el método del
proceso de desarrollo OPENUP/OAS como marco de trabajo Institucional en el
análisis, diseño, desarrollo e implantación de productos de software al interior de
la Universidad Distrital Francisco José de Caldas. SISGRAL Bogotá D.C.
11

Los principios en que se enmarcan en el método de trabajo OPENUP/OAS son:
a. Conocer a los Interesados: Se deben identificar a los grupos de interés y
trabajar de cerca con ellos para asegurarse que sus necesidades son claramente
definidas e incrementalmente satisfechas a medida que se evoluciona en el
desarrollo de la solución.
b. Separar el Problema de la Solución: Se debe estar seguro que se conoce el
problema (o una parte de él) antes de definir una solución (o una parte de ella).
c. Crear un conocimiento compartido del dominio: Se debe fomentar un
ambiente de intercambio y trabajo en el que todos los involucrados puedan
obtener constantemente la información adecuada para lograr tener una visión
compartida de lo que se debe hacer, el por qué hacerlo y cómo se está haciendo.
d. Usar escenarios y casos de uso para capturar requerimientos: Hacer uso
de escenarios y casos de uso para capturar los requerimientos funcionales del
sistema.
e. Establecer y mantener contratos de prioridades: Se deben priorizar los
requisitos y requerimientos de implementación basados en un trabajo continuo con
los grupos de interés y tomar decisiones que lleven a que el sistema siempre
incremente los beneficios ofrecidos y reduzca los riesgos.
f. Realizar negociaciones que maximicen el beneficio obtenido: Las
negociaciones costo beneficio dentro del proyecto no pueden ser independientes
de la arquitectura. Los requisitos y requerimientos establecen los beneficios que
se deben alcanzar al implementar el sistema mientras que la arquitectura es una
medida base para calcular el costo del mismo. El costo asociado con un beneficio
puede influenciar en gran medida la percepción del usuario acerca del valor real
obtenido.
g. Gestionar el entorno: El cambio es inevitable, y aunque presenta
oportunidades para mejorar los beneficios dados a los grupos de interés, un
entorno incontrolado de cambios fácilmente decantará en sistemas deficientes. Se
debe gestionar los cambios manteniendo contratos específicos con los grupos de
interés.
h. Conocer cuándo se debe parar: Sobre recargar de características un sistema
no sólo es una pérdida de tiempo y recursos sino que conduce a sistemas
innecesariamente complejos. El desarrollo debe parar cuando la calidad esperada
del sistema se alcanza.
13

i. Mantener un entendimiento común: Ser proactivo comunicándose y
compartiendo información con los participantes del proyecto y no asumir que todos
encontrarán justo lo que ellos necesitan saber o que cada persona tiene la misma
comprensión del proyecto que todos los demás.
j. Aprender continuamente: Desarrollar continuamente las habilidades técnicas e
interpersonales, aprender de los ejemplos de los colegas, aprovechar la
oportunidad, tanto de ser un estudiante de sus colegas, así como maestro de
ellos.
k. Organizar alrededor de la arquitectura: La comunicación entre los miembros
del equipo empieza a ser compleja incrementalmente. Por consiguiente, es
pertinente organizar el equipo alrededor de la arquitectura, el vocabulario y el
modelo mental compartido del sistema.
l. Desarrollar el proyecto en iteraciones: Dividir el proyecto en una serie de
iteraciones encajadas en el tiempo y planear el proyecto iterativamente.
m. Gestionar los riesgos: Atacar tempranamente los riesgos que pudieran poner
en riesgo el proyecto. Es necesario identificar y priorizar los riesgos para idear
estrategias y mitigarlos.
n. Adoptar y gestionar el cambio: Adoptar los cambios ayuda a construir un
sistema que se encamina a suplir las necesidades de los interesados. Manejar los
cambios permite reducir costos y mejorar la predicción de éstos.
o. Medir el progreso objetivamente: Si no se conoce objetivamente cómo está
progresando el proyecto, no se sabrá si éste falla o tiene éxito. La incertidumbre y
los cambios a un proyecto de software en progreso dificultan medirlo
objetivamente.2
2UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS. Guía Rápida Proceso de
Desarrollo OPENUP/OAS. Primera Edición. Bogotá, 2011. p. 1-3.
14

5.1.2. El método de trabajo
El OPENUP/OAS es un proceso iterativo e incremental que se distribuye a través
de cuatro fases: Inicio, Elaboración, Construcción y Transición en las cuales se
desarrollan transversalmente una serie de subprocesos entendiéndose estos
últimos como un conjunto de actividades, personas (Roles), prácticas (Guías) y
productos de trabajo (Artefactos) que orientan el desarrollo de software a través
del tiempo.
Cada fase puede tener tantas iteraciones como se requiera, dependiendo del
grado de complejidad y desconocimiento del dominio, la tecnología a ser usada, la
complejidad arquitectónica y el tamaño del proyecto, por nombrar algunos
factores3
.
5.1.2.1. Fases del proceso OPENUP/OAS
Fase de Inicio: En esta, los interesados (stakeholders) y los integrantes del
equipo de desarrollo, colaboran para determinar el ámbito del proyecto, sus
objetivos y determinar si el proyecto es viable.
Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las siguientes
actividades y resultados:
Tabla 1 Actividades y Tareas Fase de Inicio
Actividad Resultados
Iniciar el proyecto *Elaborar el documento Visión.
*Elaborar el Plan General del Proyecto.
*Elaborar el documento de Análisis de
riesgo.
3Ibíd., p. 4.
15

Planear y gestionar la iteración *Elaborar el Plan de Iteración.
*Elaborar el documento de evaluación de la
iteración.
*Elaborar el documento de valoración de
resultados de la iteración.
Identificar y refinar los
requerimientos y requisitos
*Elaborar la especificación de casos de uso
*Elaborar el documento de requisitos de
soporte
*Elaborar el documento casos de prueba
Llegar a un acuerdo sobre el
enfoque técnico
Elaborar el documento Bloc de Notas de la
Arquitectura
Tomada de Guía Rápida Proceso de Desarrollo OPENUP/OAS. Primera Edición. Bogotá,
2011. p. 4-5.
Al final de esta fase, como mínimo, en el proyecto:
● Se ha definido el ámbito.
● Se tiene un estimado inicial de los costos y el cronograma.
● Se ha definido y priorizado un conjunto inicial de requerimientos
funcionales y no funcionales.
● Se han identificado un conjunto de riesgos y ha propuesto las estrategias
de mitigación.
● Se han identificado un conjunto de interesados.
● Se ha creado un bosquejo de arquitectura.
Fase de Elaboración: La segunda fase dentro del ciclo de vida del proyecto. En
ella los riesgos significativos que influyen en la arquitectura son identificados y
considerados.
En esta fase:
● Se obtiene un entendimiento más detallado de los requerimientos y
requisitos.
● Se diseña, implementa válida y establece la línea base de la arquitectura.
● Se mitigan los riesgos esenciales.
● Se produce un cronograma detallado.
● Se realiza una mejor estimación de costos.
16

Las iteraciones de esta fase enfocan su esfuerzo de trabajo en las siguientes
actividades y resultados:
Tabla 2 Actividades y Tareas Fase de Elaboración
Actividad Tareas/Resultados
Planear y gestionar la
iteración
*Elaborar el Plan de Iteración.
*Elaborar el documento de evaluación de la
iteración.
*Elaborar el documento de valoración de
resultados de la iteración.
Identificar y refinar los
requerimientos
*Actualizar, depurar y aumentar el contenido de la
especificación de casos de uso.
*Actualizar, depurar y aumentar el contenido del
documento de Requerimientos de soporte.
documento Casos de prueba.
Desarrollar la arquitectura *Agregar las vistas de arquitectura al documento
Bloc de Notas de la Arquitectura.
Desarrollar un incremento en
la solución
documento Especificación de Diseño.
documento Pruebas efectuadas por el Realizador.
*Obtener el código fuente que realiza uno o varios
elementos de diseño.
*Elaboración de una Construcción del Sistema
que integre nuevos elementos (componentes
desarrollados, clases, etc.).
*Elaborar el artefacto Registro de Pruebas que
contenga los resultados de la ejecución de las
pruebas hechas por el realizador.
Probar la Solución Construida Elaborar el artefacto Script de Prueba.
Elaborar el artefacto Registro de Pruebas que
contenga los resultados de la ejecución de las
pruebas.
17

Gestionar las peticiones de
cambio
Actualizar, depurar y aumentar el contenido del
documento Lista de Unidades de Trabajo.
2011. p. 5-6.
Fase de Construcción: La tercera fase se enfoca en detallar los requisitos y
requerimientos, diseñar, implementar y probar el grueso del software y completar
el desarrollo del sistema basado en la arquitectura.
En esta fase:
 Se describen los requisitos y requerimientos restantes
 Se completan en detalles los diseños, la implementación y las pruebas del
software.
 Se libera la primera versión operativa del software (beta) del sistema.
Las actividades de esta fase son:
 Planificación y gestión de la iteración.
 Identificar y refinar requisitos y requerimientos.
 Desarrollar un incremento de solución.
 Probar la solución construida.
Fase de Transición: La última fase se enfoca en la transición del producto de
software a la plataforma tecnológica del cliente logrando que los interesados
convengan en que el desarrollo del producto cumple con los requerimientos
planteados.
Los objetivos a alcanzar en esta fase son:
● La prueba beta valida que satisfaga las expectativas del usuario. Esto,
típicamente, requiere algunas actividades de afinamiento, tales como
depuración de errores y mejora del desempeño y la usabilidad.
● El consentimiento de los interesados en que el desarrollo está completo.
Esto puede involucrar varios niveles de pruebas para la aceptación del
producto, incluyendo pruebas formales e informales y pruebas beta.
● Mejorar el desempeño en futuros proyectos a través de lecciones
aprendidas.
18

● Documentar las lecciones aprendidas y mejorar el ambiente de los
procesos y las Herramientas para el proyecto.4
5.1.3. Subprocesos OPENUP/OAS
Como se había señalado anteriormente, un subproceso es el conjunto de
actividades desarrolladas por personas con unos roles determinados, las cuales
se guían por medio de una serie de prácticas o guías para obtener ciertos
productos de trabajo denominados Artefactos, que permiten cumplir y direccionar
las fases y actividades propuestas en las cuatro fases del proceso de desarrollo de
software OPENUP/OAS.
Estos subprocesos se relacionan entre sí, siendo unas entradas o insumos
iniciales para que otros subprocesos se puedan desarrollar.5
Ilustración 1 Mapa de Subprocesos OPENUP/OAS
2011. p. 7.
4Ibíd., p. 4-7.
5Ibíd., p. 7-9.
19

Teniendo en cuenta que el proyecto se fundamenta en el análisis y la gestión de
requerimientos el subproceso de interés principal es el de Gestión de
Requerimientos y Requisitos.
Tabla 3 Subproceso de “Gestión de Requerimientos y Requisitos” del Proceso de Desarrollo
OPENUP/OAS
Subproceso Objetivo Artefactos de Salida
Gestión de
Requerimientos y
Requisitos
Recolectar, analizar, aprobar
y seguir la evolución de los
requerimientos funcionales
del Cliente o interesado y los
requisitos del software a
través de la vida del producto
y/o servicio.
*Documento Visión.
*Especificaciones de Casos
de Uso.
*Glosario.
*Requisitos de Soporte.
*Actas de Trabajo.
*Listado de requerimientos
funcionales y no funcionales.
2011. p. 8.
5.1.2.3. Roles OPENUP/OAS
Los productos de software los crean personas con diferentes intereses y
competencias. Un ambiente de grupo saludable potencia la colaboración efectiva
requiriendo una cultura compartida que fomente la creatividad y el cambio positivo.
Los roles son el rostro humano del proceso de desarrollo de software.
Dependiendo del número de personas que conforman el equipo de trabajo y las
condiciones del proyecto una persona puede asumir uno o varios roles.6
6Ibíd., p. 9-10.
20

B4lvre1596217837

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (14)

Similar a B4lvre1596217837

Similar a B4lvre1596217837 (20)

Último

Último (20)

B4lvre1596217837