SUBPROCESOS Y ACTIVIDADES EN LA INGENERÍA DE SOFTWARE

8. Procesos de la ingeniería de requerimientos

En cursos previos de Ingeniería de Software se aprende que existen diferentes

modelos para desarrollar sistemas de software (cascada, evolutivos, etc.) y la
obtención de requerimientos se ve como un subproceso de este desarrollo. Sin
embargo, visto por separado, el Análisis de Requerimientos es todo un proceso
al cual [Sommerville, 2005] llama “Ingeniería de Requerimientos” cuya meta es
crear y mantener un documento de requerimientos del sistema (María del
Carmen, 2011,p. 1).
Según (María del Carmen, 2011) este proceso general consta de cuatro
subprocesos:

 El estudio de viabilidad, que evalúa si el sistema es útil para el negocio.

 Obtención y análisis de requerimientos.
 Especificación de requerimientos: transformación de los requerimientos
en formularios estándar.
 Validación: verificar que los requerimientos realmente definen el
sistema que quiere el cliente (p. 1).

En la figura 1 se muestra el proceso de ingeniería de requerimientos.

Estudio de Obtención y análisis

viabilidad de requerimientos

Informe de Especificación de
viabilidad requerimientos
Validación de
requemientos

Modelos del Requerimientos del

sistema usuario y del
sistema

Documento de
requerimientos

Figura 1. Proceso de Ingeniería de requeriemientos

9. Subprocesos Y Actividades Durante La Producción

El proceso de producción se divide en 2 subprocesos: Construcción y

certificación. A continuación serán descritos:

9.1. Construcción

Objetivo: Construir los componentes de software concebidos en la etapa del

análisis y diseño de la solución, teniendo en cuenta el documento de
requerimientos del sistema, la definición detallada de los casos de uso,
wireframes, definición de requerimientos de datos y documento de
arquitectura, en el tiempo y con los recursos asignados según el cronograma
detallado de actividades(Rengifo, 2010, p. 56) .

Descripción del proceso. En este proceso se detallan las actividades de

construcción del sistema, con los componentes de cada una de las capas
descritas en la arquitectura y el desarrollo a nivel de Ingeniería, que soporta
la funcionalidad del sistema basándose en el documento de requerimientos
del sistema, los casos de uso detallados, wireframes, requerimientos de
datos y cada uno de los artefactos entregadas por la etapa de Análisis y
Diseño. Se realizan las pruebas de verificación de las funcionalidades por
parte de los desarrolladores (junior y senior) que garanticen que hizo la
verificación correspondiente.(Rengifo, 2010, p. 56)

Según(Rengifo, 2010) estás serían las entradas que se dan durante la

construcción:

“Entradas:
• Acta de reunión técnica
• Documento de entendimiento
• Documento SOW
• Documentos de requerimientos del sistema
• Documento de arquitectura
• Casos de uso detallados
• Plan de pruebas
• Diccionario de datos” (p. 56).
 9.1.1 Actividades:

Según(Rengifo, 2010) durante la construcción se realizan las igueintes

actividades:

 Se realiza reunión técnica de producción donde se involucre a todos

los recursos y se explique en qué consiste el proyecto, impactos y
matriz de riesgo.
 Se realiza el corte y montaje de las interfaces gráficas de usuario e
integración de los contenidos a nivel de diseño.
 Se realiza entrega de insumos de diseño a Ingeniería.
 Se realiza el desarrollo de la lógica de negocio para la solución, según
la funcionalidad definida.
 Se realizan las pruebas por parte del Ingeniero de desarrollo, que
garantizan que la versión cumple con las especificaciones (p. 57)

Doc Entrada
Acta de reunión
técnica
Documento de Registro On Data
entendimiento Doc. Requerimiento
Docuemtno SOW del sistema

Documentos de Diccionario de datos

requerimientos del Fuentes de
sistema aplicación
Docuemento de Manual de
arquitectura configuración
Casos de uso Manual de usuario
detallados
Casos de prueba
Plan de pruebas
Casos de pruebas
Diccionario de datos

Figura 2. Construcción
 Documento de requerimientos del sistema: Documento base sobre el
que se soportará todo el desarrollo y pretende lograr un mapeo de cada
uno de los requisitos a nivel de casos de uso y artefactos generados en
Ingeniería. Puede considerarse el documento consolidador del
proyecto. En esta fase debe estar totalmente diligenciado.(Rengifo,
2010, p. 58)

Diccionario de datos: Documento que describe cada una de las tablas

y vistas creadas en el modelo de datos y muestra diagramas de
asociaciones por funcionalidades. En esta fase debe estar finalizado
con todos los objetos definidos inicialmente y con los que se hayan
tenido que crear en la etapa de construcción.(Rengifo, 2010,p. 58)

Fuentes aplicación: “Líneas bases de código de aplicación en repositorio de

código definido por la compañía.”(Rengifo, 2010, p. 58)

Manual de configuración : “Documento instructivo para la instalación y

configuración del sitio.”(Rengifo, 2010, p. 58)

Manual de usuario: “Documento iinstructivo para el uso de la aplicación,

dividido en cada uno de sus módulos y que debe presentar los posibles
errores que tendría la aplicación en caso de tener problemas de
configuración.”(Rengifo, 2010, p. 59)

Tabla 3. Responsables por Artefacto Construcción

Acta Renuión Tecnica Gerente de Proyectos

Fuente de Aplicación Gerente de desarrollo

Documento de Requerimientos del sistema Gerente de proyectos – Ingeniero de requisitos

Casos de prueba por caso de uso ejecutados Ingeniero de desarrolo

por ingeniero de desarrollo
Manual de configuración Gerente de desarrollo/Ingeniero de desarrollo

Diccionario de datos Gerente de desarrollo/Ingeniero de desarrollo

Manual de usuario Ingeniero de requisitos/ Analista de calidad

Fuente:(Rengifo, 2010, p. 59)

9.2. Certificación

Objetivo: “Verificar el funcionamiento de cada uno de los componentes del

sistema y certificar que cumplen con las especificaciones indicadas en cada
uno de los documentos recibidos como insumo para realizar las
pruebas”(Rengifo, 2010, p. 60).

Descripción del Proceso. En este proceso se verifican y certifican cada uno

de los casos de uso diseñados en la etapa de análisis y diseño, se registran los
bugs encontrados y se hacen las corridas necesarias hasta la certificación de
cada funcionalidad(Rengifo, 2010, p. 60).

Según(Rengifo, 2010) estás serían las entradas que se dan durante la

certificación:
“Entradas:
• Acta de reunión técnica
• Documento de entendimiento
• Documento SOW
• Documentos De requerimientos del sistema
• Casos de uso detallados
• Plan de pruebas
• Casos de prueba
• Diccionario de datos”(p. 61).

9.2.1 Actividades:

Según(Rengifo, 2010) durante la certificación se realizan las igueintes

actividades:

 Se realiza liberación del software alfa para pruebas de integración interna,

las cuales son realizadas por el Analista de calidad.
 Se realizan pruebas de Integración Diseño e Ingeniería.
 Se realizan los ajustes que se requieren según el resultado de las pruebas, se
realiza la migración de contenidos y datos existentes, si es el caso.
 Se elaboran todos los manuales del software, manual de estilos, manual de
uso, manual de operación, manual de instalación, etc.
 Se realiza la liberación del software beta y se presenta al cliente para sus
respectivas pruebas (p. 61).
 QA
QA Registro de
Pruebas
funcionales Pruebas pruebas
Sitio beta
funcionales
Pruebas de
integración con Certificación Carta de
sistemas de certificación
terceros Pruebas Cliente
QA
Pruebas de stress
Pruebas de carga
Certificación del
sitio

Figura 3. Diagrama de flujo Certificación

Casos Prueba: Documentos en los que se detallan los casos de pruebas
ejecutados y sus resultados, se presentan las incidencias de error. Estos casos de
prueba deben ser coherentes con los casos de uso definidos para la aplicación;
en este punto deben reflejar los resultados que se dieron en la verificación por
parte del Ingeniero de desarrollo(Rengifo, 2010, p. 63).

Carta Certificación: Carta de certificación del departamento de QA, necesaria

para el montaje del software en producción o en ambiente de pruebas del
cliente. Esta carta es indispensable para el montaje de nuevos sistemas de
software y actualizaciones de desarrollo(Rengifo, 2010, p. 63).

Tabla 4. Responsable por Artefacto Certificación

Casos prueba Analista de calidad
Carta de certificación Analista de calidad
Fuente: (Rengifo, 2010, p. 63)
10. Implantación de software

10.1. Subprocesos en la implantacion de software

 Subproceso: Distribución del software ensamblado

 Generar componentes de software: “Crear componentes que deberán
ser instalados en el entorno productivo”(Mon y López Gil, 2014, p.
2).
 Empaquetar software para la distribución: “Generar paquetes de
software para que estén listos para ser instalados”(Mon y López Gil,
2014, p. 2).
 Adquirir componentes: “Adquirir los componentes de software
necesarios para llevar a cabo la implantación”(Mon y López Gil,
2014, p. 2).
 Distribuir el software: “Hacer llegar los componentes empaquetados
a cada uno de los lugares en que se deben instalar”(Mon y López Gil,
2014, p. 2).

 Subproceso: Instalación
 Análisis de la infraestructura para la puesta en marcha: “Determinar
los recursos tecnológicos de infraestructura y software necesarios
para la instalación del producto”(Mon y López Gil, 2014, p. 2).
 Auditar la configuración física: “Evaluar los recursos disponibles
para utilizar en la puesta en marcha y operación del producto
software”(Mon y López Gil, 2014, p. 2).
 Asegurar la compatibilidad de la aplicación: “Garantizar que se
tienen disponibles los recursos para el funcionamiento del software
en el nuevo entorno”(Mon y López Gil, 2014, p. 2).
 Desarrollar una copia de seguridad de la versión del sistema:
“Resguardar el estado actual del sistema en operación”(Mon y López
Gil, 2014, p. 2).
 Configurar la base de datos: “Instalar en el motor de base de datos
las entidades necesarias para el funcionamiento del software”(Mon y
López Gil, 2014, p. 3).
 Asignación de los permisos requeridos: “Dejar configurada la
seguridad de modo que el software tenga acceso a los recursos
necesarios para su funcionamiento”(Mon y López Gil, 2014, p. 3).
  Realizar la puesta en funcionamiento del software en las
instalaciones del cliente: “Dejar operativo al software en el entorno
final”(Mon y López Gil, 2014, p. 3).
 Análisis de los resultados de la instalación: “Documentar los
incidentes ocurridos en el proceso de instalación y evaluar su
impacto para la continuidad del proyecto”(Mon y López Gil, 2014, p.
3).

 Subproceso: Configuración del software

 Desarrollo de un plan de personalización de la aplicación: “Definir el
modo en que se llevará a cabo la configuración de la
aplicación”(Mon y López Gil, 2014, p. 3).
 Definición de usuarios y/o perfiles dentro de la aplicación:
“Determinar los permisos o perfiles que diferentes usuarios deben
tener en la aplicación”(Mon y López Gil, 2014, p. 3).
 Migración de la configuración del software existente: “Tener total o
parcialmente configurada la aplicación con la configuración
preexistente”(Mon y López Gil, 2014, p. 3).
 Creación de los usuarios y/o perfiles de la aplicación: “Dejar creados
en la aplicación los diferentes usuarios y/o perfiles”(Mon y López
Gil, 2014, p. 3).
 Personalización de la configuración de la aplicación: “Configurar la
aplicación de modo que cumpla con los requisitos del usuario”(Mon
y López Gil, 2014, p. 3).
 Prueba de la configuración: “Garantizar que se ha cumplido con la
configuración esperada”(Mon y López Gil, 2014, p. 3).

 Subproceso: Aceptación del software

 Definir criterios de aceptación del sistema: “Listar los casos de
prueba a realizar y los resultados esperados”(Mon y López Gil, 2014,
p. 3).
 Validación y Pruebas de Servicios: “Realizar las pruebas definidas
en el reporte de criterios de aceptación”(Mon y López Gil, 2014, p.
3).
 Aceptación de software en el entorno operativo: “Lograr que los
usuarios verifiquen que el software cumple con los criterios de
aceptación y por ello con lo requerido”(Mon y López Gil, 2014, p.
3).

 Subproceso: Conversión del sistema

  Definir estrategia de conversión: “Tener una estrategia de puesta en
marcha del software en producción”(Mon y López Gil, 2014, p. 3).
 Ejecutar plan de conversión de sistemas: “Llevar a cabo las tareas
definidas en el plan de conversión”(Mon y López Gil, 2014).
 Preparación de datos: “Obtener los datos a migrar al nuevo
software”(Mon y López Gil, 2014, p. 3).
 Migración de datos: “Dejar los datos ya migrados en el
software”(Mon y López Gil, 2014, p. 3).
 Verificación de datos ingresados: “Verificar la consistencia de los
datos migrados”(Mon y López Gil, 2014, p. 3).

 Subproceso: Capacitación de usuarios

 Preparar plan de capacitación: “Tener un plan de trabajo para la
capacitación del personal en el nuevo software”(Mon y López Gil,
2014, p. 4).
 La capacitación de los usuarios finales: “Que el personal que opera el
sistema está capacitado para hacerlo en forma autónoma”(Mon y
López Gil, 2014, p. 4).
 Capacitación personal técnico: “Que el personal de soporte de la
organización esté capacitado para realizar dicha actividad con el
nuevo software”(Mon y López Gil, 2014, p. 4).
 Capacitar a los afectados por los cambios del sistema: “Que los
diferentes usuarios que son afectados por el nuevo software
conozcan las características más relevantes que puedan
involucrarlos”(Mon y López Gil, 2014, p. 4).

 Subproceso: Operación
 Pruebas de operación: “Garantizar a los usuarios el funcionamiento
del software de acuerdo a las necesidades y con sus propios
datos”(Mon y López Gil, 2014, p. 4).
 Operación del sistema: “Realizar las operaciones habituales con el
sistema”(Mon y López Gil, 2014).
 Soporte al usuario: “Resolver las necesida-des de soporte que pueda
tener el usuario”(Mon y López Gil, 2014, p. 4).

 Subproceso: Actualización de los procesos

  Implementación del proceso: “Que los nue-vos procesos o cambios
en los existentes queden adecuadamente documentados”(Mon y
López Gil, 2014, p. 4).
 Institucionalizar un proceso gestionado: “Definir los nuevos procesos
administrativos o modificar los existentes y comunicarlo a la
organización”(Mon y López Gil, 2014, p. 4).
 Informar a la comunidad de usuarios: “Que todos los stakeholders
conozcan el cambio de software”(Mon y López Gil, 2014, p. 4).
 Gestión de Cambios: “Mantener actualizada la documentación y las
líneas base del software”(Mon y López Gil, 2014).
 Gestión del Conocimiento: “Que las lecciones aprendidas a lo largo
del proceso queden registradas en la organización”(Mon y López Gil,
2014, p. 4).

 Subproceso: Cierre del proyecto

 Confirmar que se ha cumplido con todos los requisitos: “Tener certeza que
se ha cum-plido con todo lo esperado del proyecto”(Mon y López Gil,
2014, p. 4).
 Cumplir con los criterios de conclusión del proyecto: “Validar que se ha
cumplido con los criterios de finalización del proyecto”(Mon y López Gil,
2014, p. 4).
 Aceptación formal del producto final: “Documentar la entrega y
aceptación del producto por porte de los actores”(Mon y López Gil, 2014,
p. 4).
 Cierre del Contrato: “Tener documentado que se ha cumplido con las
responsabilida-des contractuales entre las partes”(Mon y López Gil, 2014,
p. 5).
 Estimación de recursos necesarios: “Tener conocimiento sobre los
recursos que serán necesarios para la implantación”(Mon y López Gil,
2014, p. 5).
 Estimación de tiempo de implantación: “Tener conocimiento sobre el
tiempo que se necesitará para poder implantar el software”(Mon y López
Gil, 2014, p. 5).
 Estimación de costo: “Tener conocimiento sobre los costos que tendrá
asociada la implantación del software”(Mon y López Gil, 2014, p. 5).
 Definición plan de implantación: “Tener un plan de trabajo para los
procesos de implantación del software”(Mon y López Gil, 2014, p. 5).
 Definición de puntos de control: “Tener definidos los hitos de control del
plan de implantación”(Mon y López Gil, 2014, p. 5).
 Definición equipo de implantación: “Determinar los perfiles necesarios y
las personas que los cubren para conformar el equipo de
implantación”(Mon y López Gil, 2014, p. 5).
  Definición responsabilidades dentro del equipo: “Que cada una de las
actividades necesarias para la implantación tenga un responsable”(Mon y
López Gil, 2014, p. 5).
 Coordinación de las tareas: “Resolver las dificultades que puedan surgir y
asegurar el avance de las diferentes tareas de la implantación”(Mon y
López Gil, 2014, p. 5).
 Evaluación de avance: “Determinar el grado de avance de la implantación
y su correlación con el plan definido”(Mon y López Gil, 2014, p. 5).

MARÍA DEL CARMEN, G.F., 2011. Análisis de requerimientos. Publidisa Mexicana

[en línea], Disponible en:
https://www.conocimientosweb.net/dcmt/ficha25213.html.
MON, A. y LÓPEZ GIL, F., 2014. Implantación de Software, un Modelo Básico
Resumen. [en línea], pp. 5. Disponible en:
http://sedici.unlp.edu.ar/bitstream/handle/10915/41437/Documento_completo.
pdf?sequence=1.
RENGIFO, J.I., 2010. Diseño de una metodología para el proceso de software
para una compañía de tic nacional. [en línea], Disponible en:
https://repository.eafit.edu.co/bitstream/handle/10784/412/JoseIgnacio_Rengif
o_2010.pdf;jsessionid=7588E3BA3925F0EDC726897F52067A94?sequence=
1.