Procesos

Construcción de los Componentes

del Producto de la Solución de
Tecnología

Versión Autor
27/06/17 AGESIC

Página 1 de 11
Contenido
3.1 Construcción de los Componentes del Producto de la Solución de Tecnología .................................. 4
Descripción General ........................................................................................................................................ 4
Contexto del Proceso ...................................................................................................................................... 4
Nivel de Desarrollo del Proceso ..................................................................................................................... 5
Actividades del Proceso .................................................................................................................................. 6
1. Asignar tareas al equipo de desarrollo a partir del diseño de la solución técnica ........................ 6
1.1. . Planificar las tareas de transferencia ..................................................................................... 6
1.2. Conducir la instancia de inicio de desarrollo ........................................................................... 6
1.3. Asignar el conjunto de tareas de desarrollo a los integrantes del equipo ........................... 7
2. Desarrollar los componentes del producto ........................................................................................ 7
2.1. Construir el código del componente ......................................................................................... 7
2.2. Diseñar las pruebas unitarias para los componentes construidos ....................................... 7
3. Construir la documentación del producto ........................................................................................... 8
3.1. Crear el manual de usuario ........................................................................................................ 8
3.2. Crear el manual de instalación y configuración ...................................................................... 8
Roles y Expectativas de Desempeño ............................................................................................................ 9
Pautas de Trabajo Sugeridas ....................................................................................................................... 10
Desafíos del Proyecto............................................................................................................................... 10
Buenas Prácticas y Lecciones Aprendidas ........................................................................................... 10
Productos de Trabajo......................................................................................................................................11

Página 2 de 11
3.1 Construcción de los Componentes del Producto de la

Solución de Tecnología

Descripción General

El proceso de construcción de los componentes del producto de la solución de tecnología,

tiene lugar en la fase de Construcción e Implementación dentro del ciclo de vida de un
proyecto de software. Se toma como entrada el diseño realizado en la fase de Análisis y
Diseño de Sistemas, en la forma de los entregables de los procesos de creación de modelo
conceptual, lógico y físico, así como, las especificaciones de requerimientos y demás
productos de trabajo que den valor al proceso de desarrollo de software, enmarcando las
actividades de construcción para que correspondan con el cronograma del proyecto y la
estrategia de orden para el desarrollo de los componentes.

El propósito principal de este proceso es el desarrollo del software para cada uno de los
componentes de la solución. En caso que el desarrollo sea iterativo este proceso se repite
en cada iteración, incrementando las funcionalidades soportadas por cada uno de los
componentes.

Las principales actividades de este proceso son: la asignación de actividades para el

desarrollo del sistema, el desarrollo de los componentes del sistema y construir la
documentación del sistema.
Este proceso incluye las tareas de creación de los manuales del sistema, las cuales deben
comenzar en la fase de Construcción e Implementación y pueden llegar a extenderse hasta
la fase de Implementación, Estabilización y Monitorio como continuidad operativa.

Contexto del Proceso

En este proceso se debe realizar la construcción coordinada de las partes que componen
una solución de software para que las mismas se puedan integrar y formar el “todo” de la
solución proyectada.

En una primera instancia este proceso involucra la asignación de las actividades de trabajo
a realizar a los distintos equipos y a los distintos integrantes de cada equipo, con un nivel de
detalle que les permita llevar a cabo su tarea.

Página 3 de 11
En una segunda instancia para este proceso, cada equipo construye según se indica en la
especificación realizada para el componente correspondiente respaldando el conocimiento
conforme a las políticas para la gestión de la configuración establecidas.

Nivel de Desarrollo del Proceso

El proceso de “Construcción de los Componentes del Producto de la Solución de
Tecnología”, involucra los siguientes niveles de desarrollo para cada documento:
Documento NP1 NP2 NP3
Software (Código No usan patrones de Usan patrones de Usan patrones de diseño.
fuente). diseño diseño. Es tratado con políticas
Es tratado con políticas para la gestión de la con-
No existen políticas para la para la gestión de la figuración.
gestión de la configuración. configuración.
Cuentan con herramientas
para la gestión de la
configuración.

Cumple con estándares

de la organización e
internacionales, ejemplo
la W3C.
Documento manual Es comprensible por todo Tiene estructura definida. Forma parte de los activos
de usuario. el equipo de trabajo. de la organización para la
Es intuitivo y de fácil producción de
No tiene estructura navegación. documentación.
definida.
Es considerado como un
activo para la gestión del
conocimiento.

Está representado de
forma audio visual.
Documento manual Es comprensible por todo el Tiene estructura definida. Forma parte de los activos
de instalación y equipo de trabajo. de la organización para la
configuración. Es intuitivo y de fácil producción de
No tiene estructura navegación. documentación.
definida.
Es considerado como un
activo para la gestión del
conocimiento.

Está representado de
forma audio visual.

Página 4 de 11
Actividades del Proceso
Al culminar la fase de “Análisis y Diseño de Sistemas”, el equipo de trabajo cuenta con los
recursos necesarios para construir los componentes que conformaran la solución
tecnológica.
Las actividades asociadas a este proceso son:

1. Asignar tareas al equipo de desarrollo a partir del diseño de la solución técnica

En esta instancia se hace efectivo la transferencia del diseño realizado en la fase anterior
hacia los integrantes del equipo de desarrollo, y se comunica a los integrantes del equipo en
qué parte del sistema estarán trabajando y de qué forma ese componente contribuye al
todo.

1.1. Planificar las tareas de transferencia

El Gerente de proyecto debe revisar el cronograma con el fin de verificar que contemple las
actividades de transferencia de conocimientos para comenzar el desarrollo. En caso que no
existan estas tareas, deben crearse y asignarse a los integrantes del equipo que
corresponda.

1.2. Conducir la instancia de inicio de desarrollo

El Analista de sistemas (arquitecto de aplicaciones) o el Arquitecto de sistemas (arquitecto
empresarial), debe conducir una reunión en la cual se presenta a los integrantes del equipo
el contexto del proyecto, una revisión del caso de negocio que motiva el producto a construir
y la arquitectura diseñada como solución.

En la presentación de la arquitectura proyectada durante la fase de análisis y diseño del

sistema, se debe hacer foco en el diseño conceptual y en los diagramas diseño lógico de
carácter general como el diagrama de componentes, así como también algún diagrama de
secuencia correspondiente a algún caso crítico para el sistema.

En esta reunión se sugiere también comunicar el cronograma de trabajo, el orden en que

está planificado construir los componentes y los integrantes del equipo que van a estar
trabajando en cada componente.

El objetivo de esta reunión es presentar a los integrantes del equipo el sistema a construir
en su totalidad, no en profundidad, para que todos sepan en qué van a estar trabajando y
quién se va a dedicar a cada parte. Es una instancia también para contestar preguntas que
puedan surgir desde integrantes del equipo de desarrollo.

Página 5 de 11
1.3. Asignar el conjunto de tareas de desarrollo a los integrantes del equipo
Quien lidere el desarrollo se reúne con cada uno de los integrantes del equipo de desarrollo
o con un conjunto de ellos y les comunica las actividades de trabajo en los que deben
trabajar. En esta instancia el líder indica pautas y sugerencias a tener en cuenta sobre cómo
se debe implementar cada tarea de programación.

Esta es una instancia de asignación de responsabilidades, pero a diferencia de la reunión de

inicio del desarrollo, la audiencia es menos numerosa y el nivel de detalle técnico manejado
es mayor.

Importante: Es necesario en esta instancia lograr el compromiso de los integrantes del

equipo para con las tareas que se les asignan y los tiempos planificados.

Cualquier modificación a la estimación de esfuerzo que surja a partir de estas instancias de

revisión, debe ser comunicada al Gerente de Proyecto para tomar las acciones que
correspondan en cada caso.

2. Desarrollar los componentes del producto

2.1. Construir el código del componente

El programador construye el componente que se le asignó, según las indicaciones recibidas,
tomando como referencia:

• El diagrama de componentes del sistema.

• Diagrama de clases del sistema.

• Diagramas de secuencia.

• Casos de uso.

• Guías y Estándares de desarrollo o implementación según corresponda.

• Especificación de requerimientos.

Si surgen dudas del escenario de negocio en el cual el componente actuará, el programador

debe intentar resolverlas con la documentación, y en caso que no pueda, debe escalar al
Arquitecto, al Analista o al Gerente de proyecto en su defecto.

2.2. Diseñar las pruebas unitarias para los componentes construidos

El programador basado en los servicios que establece el diccionario de servicios del sistema
que debe brindar el componente, debe definir las pruebas unitarias que va a utilizar para
programar el componente correspondiente.

Página 6 de 11
Las pruebas unitarias pueden no ser automáticas, en particular si el componente a
desarrollar es de presentación, pero los mismos deben ser verificables y arrojar un resultado
de tipo “Pasa / No pasa” luego de su ejecución.

Luego de creado todo el código necesario para la obtención del componente, se deben
ejecutar las pruebas unitarias.

Haciendo uso de la definición de pruebas unitarias realizadas y la implementación

construida del componente, el programador ejecuta las pruebas unitarias, manualmente o
automáticamente según sea el caso para comprobar que el componente realizado funciona
correctamente, y que su salida es la esperada para una entrada especificada.

Por cada prueba que falle, el programador es el responsable de corregir el código y ejecutar
nuevamente la prueba hasta lograr un resultado esperado.

NOTA: Es deseable que el porcentaje de cobertura de código logrado en las pruebas

unitarias utilizadas sea el mayor posible, e incluya los componentes críticos de la solución.

3. Construir la documentación del producto

Esta actividad cierra la construcción de los componentes del producto, e incluye

básicamente: la construcción del manual de usuario y el manual de instalación y
configuración de la solución construida.

3.1. Crear el manual de usuario

El Líder de Desarrollo o Gerente de Proyecto debe asignar las personas idóneas para la
creación del manual de usuario, el cual debe estar basado en la documentación de análisis y
diseño, y al avance en la construcción del producto. El fin de este documento es introducir e
ilustrar el uso del sistema a un usuario final en las tareas operativas derivadas del uso del
sistema construido.

Generalmente, la recomendación es que la documentación de usuario sea escrita en

vocabulario no técnico, y abstraída de toda referencia a la implementación realizada. Las
excepciones son cuando la aplicación o interfaz construida es para fines meramente
técnicos (Servicios Web, motores de integración, protocolos, etc.), y la audiencia comprende
esa situación.

3.2. Crear el manual de instalación y configuración

El técnico asignado por el líder de equipo debe crear el documento de instalación basado en
la documentación de análisis y diseño, y en el paquete de instalación. El fin de este
documento es ilustrar el proceso de instalación del producto, y está dirigido al personal
técnico del cliente, o los potenciales usuarios.
Página 7 de 11
Roles y Expectativas de Desempeño
Se espera que los profesionales tengan la capacidad de comprender la
documentación de diseño y requerimientos del sistema y puedan crear las estructuras
de códigos necesarias en los lenguajes de programación y tecnologías seleccionadas
en el diseño.

Los roles que pueden ser asociados a este proceso son:

Rol Función

 Realizar seguimiento y control al proyecto buscando

asegurar el éxito de la solución tecnológica.

Gerente de Proyecto  Establecer métricas para la gestión del proyecto y

calidad del producto conjuntamente con el equipo de
trabajo.
 Dirigir y motivar al talento humano involucrado en el
proyecto.

 Tomar las decisiones técnicas para la construcción de

Arquitecto de la solución tecnológica.
Sistemas/Arquitecto  Apoyar al Desarrollador de Software en la
Empresarial construcción promoviendo se cumplan los estándares
y mitigando los riesgos técnicos.

Diseñador/Desarrollador  Construir las interfaces gráficas de usuario según lo

de interfaces de usuario especificado en el diseño.

 Participar en las reuniones de trabajo para identificar

tempranamente posibles defectos en los
requerimientos.
Especialista de Calidad
de Software/Probador de  Contribuir con los aspectos de calidad necesarios a
Software ser incluidos en el proyecto.
 Apoyar en definición de las pruebas unitarias.

Desarrollador/Integrador  Construir los componentes con las tecnologías y

de software lenguajes de programación especificados en el diseño
de la so- lución.
 Integrar los componentes siguiendo el diseño.

Página 11 de 11
Pautas de Trabajo Sugeridas
1. Comunicación asertiva: Es pilar fundamental para interpretar el diseño y los
requerimientos.
2. Gestión de la configuración adecuada: Fundamental para asegurar la calidad del
producto y asegurar que no hayan perdidas de información en los productos de
trabajo.
3. Trabajar con el área de pruebas de software: Esencial trabajar con el área de
calidad de pruebas de forma conjunta, buscar ayuda de esta área es importante para
que el software sea un gran producto de trabajo y nuestro cliente quede satisfecho
con los resultados deseados. Los probadores de software ayudaran a ver los
defectos que el desarrollador no pudo ver y viceversa. Estos dos roles se
complementan y juntos generaran un producto con la calidad deseada.

Desafíos del Proyecto

1. Encontrar desarrolladores de software con las capacidades requeridas.
2. Lograr construir un software que satisfaga al cliente.
3. Lograr cumplir con los tiempos planificados.
4. Lograr que la solución construida sea segura, fácil de usar, accesible y no tenga
problemas de lentitud.

Página 11 de 11
Buenas Prácticas y Lecciones Aprendidas

Independientemente de la metodología a usar, existen prácticas comunes que aplican al

desarrollo de los componentes.

1. Usar Arquitecturas basadas en componentes: Para tener mejor y mayor control

del software desarrollado se recomienda el mismo sea estructurado como divisiones
pequeñas de un gran sistema. A cada división le llamaremos componente. La suma de
cada componente conformará el sistema, por ende, el sistema será la sumatoria de
todas las divisiones. Esta arquitectura basada en componentes aplica a cualquier
metodología de desarrollo de software, es independiente del proceso, de los avances
tecnológicos o la cantidad y calidad de talento humano utilizado para crear un producto.
Cuando dividimos ese producto en piezas más pequeñas, controlables, ajustables,
intercambiables, lo que nos queda son grupos cohesivos de código, fuente o ejecutable,
con interfaces y comportamiento bien definidos que proporcionan un fuerte
encapsulamiento de su contenido. Una arquitectura así tiende a reducir el tamaño y la
complejidad de la solución y, por supuesto, es más robusta y resistente. Hoy, las
plataformas como J2EE suministran las referencias arquitectónicas que necesitamos
para diseñar y construir soluciones basadas en componentes.
2. Desarrollar de manera iterativa: además de dividir la arquitectura y productos de
software en los proyectos, nos encontramos que el mismo proyecto está sujeto a un
fraccionamiento que ha mostrado ser muy efectivo. La división de un proyecto en
grupos continuos de proyectos más pequeños, sujetos a incesante revisión, dinámicos y
evaluables, hace posible que tengamos completo control de todo el proyecto.
3. Verificación continúa de la calidad del software: se debe evaluar la calidad de
todos los artefactos en distintos puntos del ciclo de vida del proyecto, a medida que este
crece. Estos artefactos deben ser validados al término de cada actividad o etapa que los
produce. Específicamente, a medida que se producen componentes ejecutables del
sistema, estos se deben someter a un proceso de pruebas que abarque los distintos
escenarios para los cuales fueron construidos (todos los escenarios, hasta aquel que
solo va a acontecer una vez en la vida útil del sistema y quizás hasta el que nunca va a
suceder pero que es posible que ocurra). Este proceso de pruebas conduce a la
depuración del sistema y a la eliminación de los defectos arquitectónicos de la
aplicación. Estas pruebas deben ser realizadas por el desarrollador y se denominan
pruebas de caja blanca o pruebas unitarias.
Página 11 de 11
 4. Controlar los cambios hechos al software: Los requisitos de los sistemas están
sujetos a cambios. Estos cambios deben ser controlados para mitigar los posibles
efectos que pueden ocasionar el incluir cambios errados o con defectos en un sistema
que está en producción y ha sido satisfactoriamente aceptado por el cliente.

Productos de Trabajo
Los documentos que deberán generarse en este proceso son:
1. Software (Código fuente). Estructuras de código creadas para cada componente
con los lenguajes de programación y tecnologías seleccionadas en el diseño.
(métodos, constructores, instancias, interfaces, servicios Web, interfaces de usuario,
clases, objetos, entre otros)
2. Documento manual de usuario.
3. Documento manual de instalación y configuración.

Página 11 de 11