INSTITUTO TECNOLÓGICO SUPERIOR DE

URUAPAN

INGENIERÍA EN SISTEMAS
COMPUTACIONALES

CLAVE: ACD-0908

6° SEMESTRE GRUPO B

Ingeniería de Software
Construcción del Sistema

P R E S E N T A

Alfaro Romero Alexis Jair

Docente:
Dra. María Magdalena Gutiérrez Constantino
Instituto Tecnológico Superior de Uruapan

URUAPAN, MICH. 26/03/2019

1
 Índice:

Introducción………………………………………………………………………………3

Desarrollo...………………………………………………………………………………4

Conclusiones……………………………………………………………………………11

Bibliografía………………………………………………………………………………12

Foto de Equipo……………………………………………………………………………13

2
 Introducción:

Desarrollar un software significa construirlo simplemente mediante su descripción. Está es

una muy buena razón para considerar la actividad de desarrollo de software como

una ingeniería. En un nivel más general, la relación existente entre un software y su entorno

es clara ya que el software es introducido en el mundo de modo de provocar ciertos efectos

en el mismo.

Aquellas partes del mundo que afectarán al software y que serán afectadas por él será

el Dominio de Aplicación. Es allí donde los usuarios o clientes observarán si el desarrollo

del software ha cumplido su propósito.

Una de las mayores deficiencias en la práctica de construcción de software es la

poca atención que se presta a la discusión del problema. En general los desarrolladores se

centran en la solución dejando el problema inexplorado. El problema a resolver debe ser

deducido a partir de su solución.

Esta aproximación orientada a la solución puede funcionar en campos donde todos

los problemas son bien conocidos, clasificados e investigados, donde la innovación se ve en

la detección de nuevas soluciones a viejos problemas.

Pero el desarrollo de software no es un campo con tales características. La versatilidad de

las computadoras y su rápida evolución hace que exista un repertorio de problemas en

constante cambio y cuya solución software sea de enorme importancia.

3
 Desarrollo:

La construcción del sistema es un proceso de crear un sistema ejecutable y completo al

compilar y vincular los componentes del sistema, librerías externas, archivos de

configuración, etcétera. Las herramientas de este y las de gestión diversiones deben

comunicarse, puesto que el proceso de construcción implica extraer versiones del

componente del repositorio administrado por el sistema de gestión de versiones. La

descripción de configuración que se usa para identificar una línea base utiliza también la

herramienta de construcción del sistema.

La construcción es un proceso complejo, donde suelen ocurrir errores, ya que hay tres

diferentes plataformas de sistema que pueden estar implicadas:

1. Sistema de desarrollo: incluye herramientas de desarrollo, como los compiladores,

editores de código fuente, etcétera. Los desarrolladores sacan código del sistema de

gestión de versiones hacia un espacio de trabajo privado mucho antes de hacer

cambios al sistema.

Esto supone usar herramientas de construcción locales que usan versiones de

componentes sacadas en el espacio de trabajo privado.

4
 2. Servidor de construcción: usado para construir versiones ejecutables definitivas

del sistema. Éste interactúa estrechamente con el sistema de gestión de versiones.

Los desarrolladores ingresan código a este sistema antes de que se construya. La

elaboración del sistema puede depender de librerías externas que no se incluyen en

el sistema de gestión de versiones.

3. Entorno objetivo: plataforma donde se ejecuta el sistema. Éste puede ser el mismo

tipo de computadora que se usó para los sistemas de desarrollo y construcción. con

frecuencia es más pequeño y sencillo que el entorno de desarrollo. Para sistemas

grandes, el entorno objetivo puede incluir bases de datos y otros sistemas COTS que

no pueden instalarse en máquinas desarrollo. En ambos casos, no es posible

construir y probar el sistema en la computadora de desarrollo o en el servidor de

construcción.

Para sistemas embebidos puede instalarse un entorno de simulación en el entorno de

desarrollo para pruebas, en vez de usar la plataforma de sistema embebido real. Dichos

simuladores pueden ofrecer mejor soporte de depuración que el disponible en un sistema

embebido.

La construcción del sistema implica ensamblar una gran cantidad de información acerca del

software y su entorno operacional. Entonces, para cualquier sistema aparte de los pequeños,

siempre tiene sentido usar una herramienta de construcción automatizada para crear una

construcción del sistema.

5
Existe una gran cantidad de herramientas de construcción disponibles, y un sistema de

construcción ofrece algunas características o todas ellas:

1. Generación de rutinas (scripts) de construcción: Si es necesario, el sistema de

construcción debe analizar el programa en construcción, identificar los componentes

dependientes y generar automáticamente una rutina de construcción.

2. Integración del sistema de gestión de versiones: El sistema de construcción debe

sacar las versiones de componentes requeridas del sistema de gestión de versiones.

3. Recopilación mínima: El sistema de construcción debe establecer qué código

fuente necesita volver a compilarse y establecer las compilaciones si así se requiere.

4. Creación de sistema ejecutable: El sistema de construcción debe vincular los

archivos de código de objeto compilado entre sí y con otros archivos requeridos,

como las librerías y los archivos de configuración, para crear un sistema ejecutable.

5. Automatización de pruebas: Algunos sistemas de construcción pueden efectuar

pruebas automatizadas utilizando herramientas de automatización de pruebas como

Junit. Estas comprueban que la construcción no se haya “roto” por los cambios.

6. Informes: El sistema de construcción debe ofrecer informes sobre el éxito o fracaso

de la construcción y las pruebas que se efectuaron.

7. Generación de documentación: El sistema de construcción puede generar notas

referentes a las páginas de ayuda de la construcción y del sistema.

6
La rutina de construcción incluye la especificación de la configuración, de manera que el

lenguaje de escritura de rutinas utilizado generalmente es el mismo que el lenguaje de

descripción de la configuración. El lenguaje de configuración incluye sentencias para

describir los componentes del sistema a incluir en la construcción y sus dependencias.

Puesto que la compilación es un proceso de cómputo intensivo, las herramientas para

soportar la construcción de sistemas se diseñan por lo general para minimizar la cantidad de

compilación que se requiere. Esto se hace comprobando si está disponible una versión

compilada de un componente. De ser así, no hay necesidad de volver a compilar dicho

componente.

La forma en que se hace esto es asociar una firma única con cada archivo donde se

almacene un componente del código fuente. El código objeto correspondiente, que se

compiló a partir del código fuente, tiene una firma relacionada que identifica cada versión

del código fuente y cambia cuando éste se edita. Al comparar las firmas en los archivos de

código fuente y objeto, es posible decidir si el componente del código fuente se usó para

generar el componente de código objeto.

Tipos de firmas:

 Modificación de marca de tiempo (timestamp0:)

La firma en el archivo del código fuente es la fecha y hora de cuándo éste se

modificó. Si el archivo del código fuente de un componente se modifica después del

archivo del código objeto relacionado, entonces el sistema supone que se requiere

“recopilación” para crear un nuevo archivo del código objeto

7
  Sumas de verificación (checksums) de código fuente:

La firma en el archivo del código fuente es una suma de verificación calculada a

partir de datos en el archivo. Una función checksum calcula un número único

usando el texto fuente como entrada. Si se modifica el código fuente generará una

suma diferente. La suma de verificación se asigna al código fuente justo antes de la

compilación e identifica de manera exclusiva el archivo fuente. Entonces el sistema

de construcción etiqueta el archivo de código objeto generado con la firma

checksum. Si no hay archivo de código objeto con la misma firma que el archivo de

código fuente a incluir en un sistema, entonces es necesario recompilar el código

fuente.

El enfoque checksum tiene la ventaja de permitir muchas versiones diferentes del código

objeto de un componente para mantenerse al mismo tiempo. La firma es el vínculo entre el

código fuente y objeto. Los archivos de código fuente y de código objeto tienen la misma

firma.

Los métodos ágiles recomiendan que los componentes de sistema muy frecuentes deben

realizarse con pruebas automatizadas (pruebas de humo) para descubrir problemas del

software. Los componentes frecuentes pueden ser parte de un proceso de integración

continua:

8
Pasos:

1. Sacar la línea principal del sistema de gestión de versiones hacia el espacio de

trabajo privado del desarrollador.

2. Construir el sistema y efectúe pruebas automatizadas para garantizar que el sistema

construido pasa todas las pruebas. Si no lo hace, la construcción se descompone y

hay que informar a quienquiera que ingrese al último sistema línea base (baseline).

3. Realizar los cambios a los componentes del sistema.

4. Construir el sistema en el espacio de trabajo privado y vuelva a efectuar las pruebas

del sistema. Si las pruebas fallan, continúe la edición

5. Una vez que el sistema pasa sus pruebas, ingresar en el sistema de construcción,

pero no confirme como una línea base nueva del sistema

6. Construir el sistema en el servidor de construcción y efectúe las pruebas. Necesita

hacer esto en caso de que otros hayan modificado componentes luego de que usted

los sacó del sistema. Si éste es el caso, saque el componente que falló y edítelo de

modo que las pruebas pasen en su espacio de trabajo privado

9
 7. Si el sistema pasa sus pruebas en el sistema de construcción, confirmar entonces los

cambios que hizo como una nueva línea base en la línea principal del sistema.

El sistema más reciente en la línea principal es el sistema funcional definitivo. Sin

embargo, aunque la integración continua es una buena idea, no siempre es posible

implementar este enfoque a la construcción del sistema.

Las razones para esto son:

1. Si el sistema es muy grande, puede tardar mucho tiempo construir y probar. Por lo

tanto, no es práctico construir muchas veces al día dicho sistema.

2. Si la plataforma de desarrollo es diferente de la plataforma objetivo, tal vez no sea

posible efectuar pruebas del sistema en el espacio de trabajo privado. Puede haber

diferencias en el hardware, el sistema operativo o el software instalado. Por

consiguiente, se requiere más tiempo para probar el sistema.

Para sistemas grandes o sistemas donde la plataforma de ejecución no es la misma que la

plataforma de desarrollo, la integración continua quizá no sea práctica. Ante tales

circunstancias se puede usar un sistema que se construya diariamente.

Características de esto:

1. La organización de desarrollo establece un tiempo de entrega (por ejemplo, 2 P.M.)

para los componentes del sistema. Si los desarrolladores tienen nuevas versiones de

los componentes que escriben, deben entregarlas en ese plazo. Los componentes

pueden estar incompletos, pero deben ofrecer alguna funcionalidad básica que

pueda ponerse a prueba.

2. A partir de dichos componentes se crea una nueva versión del sistema al

compilarlos y vincularlos para formar un sistema completo.

10
 3. Entonces este sistema se entrega al equipo de pruebas, que realiza un conjunto de

pruebas de sistema predefinidas. Al mismo tiempo, los desarrolladores todavía

trabajan en sus componentes, añaden funcionalidad y reparan las fallas descubiertas

en pruebas anteriores.

4. Las fallas que se descubren durante las pruebas del sistema se documentan y

regresan a los desarrolladores del sistema, quienes reparan dichas fallas en una

versión posterior del componente.

Las ventajas de usar componentes frecuentes de software son que aumentan las

posibilidades de descubrir de manera oportuna durante el proceso los problemas que surgen

a partir de las interacciones de los componentes.

Conclusiones:

Conclusión de Alfaro Romero Alexis Jair:

La construcción del sistema es un tema muy importante ya que es el procese de la creación

de un sistema ejecutable y completo al ensamblar una gran cantidad de información acerca

del software, archivos del programa, librerías, etc. Para la creación de estos sistemas

existen herramientas que hacen la construcción del sistema automáticamente.

Conclusión de Roberto Jesús Picazo

Las firmas son importantes para poder diferenciar versiones de un proyecto y tener un

control sobre los desarrolladores, ya que viendo el control de versiones se puede saber

quien cometio un error y asi poder corregirlo, ademas de que los pasos para poder corregir

errores nos ayudan a eficientar el tiempo de desarrollo y correcion.

11
Conclusión de Oseguera Mendoza Eduardo Daniel

La construcción del sistema tiene temas importantes como integración continua, tomando

en cuenta puntos pro, para mejorar el desarrollo y la productividad, como de los

desarrolladores y testers. De esta forma ahorra mucho dinero la empresa y a los mismos

empleados, haciendo todo más sencillo y en solo algunos casos, dependiendo del software.

Conclusión de Meléndez Ávila Jennifer

La construccion de sistemas es importante ya que con esto podemos llegar a desarrollar

ordenadamente nuestro codigo, ya que cuenta con procesos muy claros, para llevar dicho

orden, donde podemos llegar a colocar una gran cantidad de información y es muy

completo con al compilar, aunque como todo existen una posibilidad de se pueda llegar a

un error.

Bibliografía:
1.-|, J. H. (s.f.). Actualizacion informatica . Obtenido de
https://www.fing.edu.uy/cpap/cursos/construcci%C3%B3n-de-software

2.-G.Rosas, B. (s.f.). construccion y pruebas del software. Obtenido de

3.-Pressman, R. (Sexta edición. Roger. Pressman). Ingernieria de software .

4.-Sommerville, I. (9 edicion. ). ingeniería de software.

5.- Ian Sommerville. Ingeniería de software Novena edición.

12
8.-Manuel Cillero. (2009). Construcción del sistema de información CSI.
24/03/2019, de manuel.cillero.es Sitio web: https://manuel.cillero.es/doc/metrica-
3/introduccion/procesos-principales/desarrollo/csi/
9.-Anónimo. (2011). Metodología de Ingeniería del Software para el desarrollo y
mantenimiento de sistemas . 24/03/2019, de Juntaex Sitio web:
http://www.juntaex.es/filescms/con01/uploaded_files/dgaeti/IngenieriaSoftwareGob
ex.pdf
10.- Ángel peña. (2009). Construcción de sistemas de información. 24/03/2019, de
prezi Sitio web: https://prezi.com/eo7eec7gkaeb/construccion-de-sistemas-de-
informacion/

Foto del Equipo:

13