Universidad Nororiental Privada “Gran Mariscal de Ayacucho”

Facultad de Ingeniería
Escuela de Sistemas
Ingeniería de Sistemas
VIII Semestre
Sección: 6S1203
Sistemas de Información II

PROFESOR: BACHILLER:
Ing. Luis Mejías Raúl Pismante G.
C.I. 25.087.977

Ciudad Bolívar, Marzo, 2018

 UNIDAD I: Diagramas de Paquete (DP)

Se entiende por “Diagrama” como un gráfico que, puede ser simple o

complejo y con unos pocos o muchos elementos, sirve para simplificar la
comunicación y la información sobre un proceso o un sistema en específico;
mientras que el “Paquete” es la agrupación de un conjunto de objetos o
cosas.

En el Lenguaje Unificado de Modelo (UML, en inglés), los Diagramas

de Paquetes se emplean como un mecanismo de documentación masiva
para aquellos proyectos de software o sistemas de información muy extensos
y complejos; organizando y agrupando los elementos del análisis, diseño o
construcción en los denominados “paquetes”, con una detallada relación de
dependencia entre ellos. Estos diagramas se caracterizan por:

 Agrupar y encapsular los elementos en unidades lógicas individuales.

 Tener una interfaz y una realización de éstas interfaces.
 Anidar unos paquetes dentro de otros.
 Establecer una dependencia entre los paquetes.
 Plantear una arquitectura a nivel macro.

Los paquetes son abstracciones que permiten gestionar la

complejidad en los diversos modelos de un software, como los Diagramas de
Clase, de Uso, de Secuencia, entre otros.

Para ello, se agrupan aquellos elementos relacionados entre sí, de

acuerdo a algún criterio; aunque esto no evita que ocurra una dependencia
estereotipada entre los paquetes, es decir, que algún elemento de un
paquete (fuente) dependa de los elementos contenidos en otro paquete
(destino).

2
 Existen tres (3) tipos de relaciones o estereotipos de dependencia
entre paquetes:

1. Importación (import): Añade los elementos públicos del paquete

destino al espacio de nombres público del paquete origen.

2. Acceso (access): Añade los elementos públicos del paquete destino al

espacio de nombres privado del paquete origen.

3. Combinación (merge): Fusiona el contenido del paquete origen con el

paquete destino.

Los estereotipos se representan con el nombre de la dependencia

dentro de un par de símbolos “mayor” y “menor”, respectivamente. Por
ejemplo:
<<import>> <<access>> <<merge>>

Las dependencias se representan visualmente mediante una flecha

discontinua que inicia en el paquete origen y apunta hacia el paquete
destino.

Cabe destacar que la generalización de paquetes también ocurre y

suele utilizarse para especificar familias de paquetes. Al igual que la
generalización entre clases, los paquetes hijos heredan los elementos del
paquete padre.

La visibilidad de los elementos son controlados por los paquetes que

los contienen, esta misma se denota anteponiéndole uno de los siguientes
símbolos en sus nombres: Positivo (+), Negativo (-) y Numeral (#).

3
+: Público, visible dentro y fuera del paquete. Es accesible desde cualquier
lugar.

-: Privado, visible dentro pero no fuera del paquete No es accesible por otro
paquete hijo, por más que esté en el mismo paquete padre.

#: Protegido, visible sólo desde el interior del paquete y desde los paquetes
hijos.

4
 UNIDAD II: Fase de Construcción

La Fase de Construcción es aquella etapa que toda metodología en

desarrollo de software realiza hasta llegar al punto en que el sistema de
información ya está listo para ser sometido a las pruebas rendimiento, con el
fin de detectar y solucionar todos los errores que se vayan presentando.

En resumen, esta etapa desarrollo de software es un proceso iterativo

de ensayo y error, con solución.

Dicha fase también se conoce como Versión Beta o Preliminar, se

define como aquella versión de software que ha pasado la etapa de prueba
interna, llamada "Alfa", y ha sido liberado gratuitamente a los usuarios para
que le hagan las pruebas de funcionamiento en busca de errores y fallas
técnicas, antes de lanzarlo oficialmente como una Versión Final del mismo.

En otras palabras, la versión Beta de un software suele ser un

prototipo del producto final que está destinado al lanzamiento público, luego
de eliminar la gran mayoría o todos los problemas técnicos.

Manual de Usuario
También llamado como Guía de Usuario, es un documento escrito
que, puede ser en formato físico (impreso en papel) o lógico (Bloc de Notas,
PDF, Word), está destinado para proporcionar asistencia técnica a las
personas (usuarios) que utilizan un software, a través de instrucciones sobre
cómo accionar correctamente las funciones.

Generalmente, los manuales de usuario son redactados por escritores

técnicos, como por ejemplo los programadores o el personal de soporte, en
un lenguaje sencillo y sin demasiados tecnicismos, e incluyen capturas de

5
pantalla de cómo el sistema debería ser junto con unos pasos detallados que
debe realizar el usuario para concretar las distintas opciones disponibles.

Cabe destacar que estos manuales o guías son creados en la versión

preliminar de cualquier sistema de información, sin importar que el mismo
posea ciertas deficiencias aún por corregir, a partir de la recopilación de
todos los datos desde su fase diseño hasta la fase de construcción.

Arquitectura Terminada
Una Arquitectura es el diseño estructural integrado de un sistema, sus
elementos y definiciones dependen de los requerimientos proporcionados.

En los sistemas de información, se asume que una arquitectura es un

plano abstracto que incluye los diseños de procesos de un sistema, basado
en los principios dentro de un marco metodológico. Según el Ingeniero de
Software Canadiense Phillippe Kruchten en 1999, una arquitectura:

“Es el conjunto de decisiones significativas sobre la organización de

un sistema de software, la selección de los elementos estructurales y sus
interfaces que componen el sistema, junto con su comportamiento tal como
se especifica en las colaboraciones entre esos elementos, la composición de
estos elementos estructurales y comportamentales en subsistemas
progresivamente más grandes, y el estilo arquitectónico que guía dicha
organización.”

La arquitectura no es el software operativo, es una representación que

permite: 1) Analizar la efectividad del diseño para cumplir los requerimientos
establecidos; 2) Considerar alternativas arquitectónicas en una etapa en la
que hacer cambios al diseño todavía es relativamente fácil y, 3) Reducir los
riesgos asociados con la construcción del software.

6
 Se dice que una arquitectura está “terminada” cuando el arquitecto de
software construyó el diseño propuesto de manera que satisface realmente
todos los requerimientos necesarios por la empresa, o cualquier
organización, los cuales son la disminución de mantenimiento y costos, y la
incrementación de los niveles de calidad y usabilidad.

Aunque se considera “terminada”, todavía falta aplicarle ciertas

pruebas o técnicas para detectar los posibles errores o discrepancias en su
diseño, antes de comenzar realmente la Fase de Construcción que conlleva
a la codificación del mismo por parte de los programadores.

Lista de Riesgos (Actualizada)

Al terminar de realizar el diseño de una arquitectura o software en
general, siempre se quiere asegurar que el proyecto satisface los
requerimientos anteriores y analizar los riesgos que causarían en diferentes
sucesos o escenarios.

En otras palabras, el riesgo de no tener la seguridad sobre qué pasará

(incertidumbre) en el desarrollo temprano ocasionará fuertes consecuencias
(pérdida) en fases o etapas posteriores del proyecto. Así como también,
puede resultar fatal si se descubren problemas en su diseño arquitectural
luego de implementar el sistema de información o software.

Por lo tanto, es importante que en todo proyecto de desarrollo de

software se tenga una lista de (posibles) riesgos que afecten negativamente
cualquier aspecto del mismo, y que ésta siempre se mantenga actualizada
ante cada nuevo descubrimiento.

Para crear las listas y actualizarlas, los riesgos se categorizan de la

siguiente manera:

7
  Riesgos del Proyecto: Amenazan la planificación temporal del
proyecto y provoca que los costos se incrementen. Estos riesgos
identifican los problemas de presupuesto, la asignación y organización
del personal, los recursos materiales y los requisitos de los clientes.

 Riesgos Técnicos: Comprometen la calidad del software a desarrollar,

incluso su implementación puede dificultarse o volver imposible.
Dichos riesgos se relacionan con problemas de diseño,
implementación, de interfaz, verificación y de mantenimiento.

 Riesgos de Negocio: Dificultan la viabilidad del producto a construir

para su venta en el mercado y limita su alcance. Los principales
candidatos son cincos (5):

1. Construir un producto, o sistema, excelente que no quiere nadie

(riesgo de mercado).

2. Construir un producto que no encaja en la estrategia comercial

general de la compañía (riesgo estratégico).

3. Construir un producto que el departamento de ventas no sabe

cómo vender (riesgo informativo).

4. Perder el apoyo de una gestión experta debido a cambios de

enfoque, o a cambios de personal (riesgo de dirección).

Lista de Artefactos
Se entiende por Artefacto, en el desarrollo de software, como
cualquier herramienta o método que se emplea durante una o todas las

8
etapas de un proyecto y, depende de las exigencias que se demanden o las
actividades que se realicen.

Los artefactos a utilizar están relacionados con la naturaleza

específica de cada proyecto de software, por lo que sus listas variarán
mucho con los objetivos puntuales, de acuerdo a la fase y/o actividad
ejecutada.

En la siguiente tabla (se puede entender como lista), se puede

apreciar los artefactos asociados a algunas de las actividades principales
realizadas en la ejecución de un proyecto bajo estudio.

Actividad Artefacto
 Casos de uso
 Diagrama de Actividades
 Diagrama de Estados
Requerimientos  Requisitos No Funcionales
 Prototipo Interfaz de Usuario
 Análisis de Riesgos
 Glosario
 Capas de Análisis
 Clases de Análisis y/o
Colaboración
Análisis y diseño  Modelo de Datos
 Capas de Diseño
 Diagrama de Secuencia
 Clases de Diseño
 Diagrama de Despliegue
Implementación
 Diagrama de Componentes

9
  Plan de Pruebas
 Procedimiento
Pruebas
 Casos
 Reporte de incidentes
Administración del  Cronogramas
Proyecto  Reportes de progreso

Pruebas del Sistema de Información

De acuerdo a González (2016):

En un proyecto de desarrollo de software pueden aparecer errores en

cualquiera de las etapas de su ciclo de vida, algunos de ellos incluso
permanecen sin ser descubiertos, de ahí radica importancia de las pruebas
en desarrollo de software.

Hay una gran probabilidad de que el código final tenga errores tanto
de requerimientos, como de diseño o de funcionalidad. Identificar estos
problemas antes de que ocurran en un entorno crítico, es necesario realizar
pruebas de software, una parte muy importante del proceso pero también
muy costosa.

Sin embargo, se debe tener en cuenta que el costo debido a un fallo

mientras está el software en funcionamiento puede llegar a ser mucho mayor.
De este modo, los objetivos principales al realizar pruebas serán los
siguientes:

 Detectar un error específico.

 Descubrir errores no descubiertos antes.
 Tener un buen caso de prueba.

10
Tipos de pruebas
La clasificación de las pruebas, según la forma en que se ejecutan los
siguientes:

 Pruebas Manuales: Las que realiza el usuario paso a paso.

 Pruebas Automáticas: Consiste en el uso de otro software y la

comparación de los resultados obtenidos y los esperados. Permite
adicionar pruebas cuya ejecución manual sería tediosa y/o difícil.

También se dividen en distintos niveles, que van desde probar

módulos individuales hasta pruebas de todo el sistema en su conjunto,
siendo éstos:

 Pruebas Unitarias: una prueba unitaria es la manera de comprobar el

correcto funcionamiento de un módulo de código, permitiendo
asegurar que todos los módulos del sistema desarrollado funcionen
correctamente por separado.

 Pruebas de Integración: Si todo individualmente funciona bien, ¿por

qué debería fallar cuando se une? Pues sí, puede fallar al unir módulo
que por separado funcionan correctamente. Para evitar esto, existen
las pruebas de integración, cuyo objetivo es coger módulos, a los que
se aplicó las pruebas de unidad, y construir una estructura de
programa que determine el diseño.

 Pruebas de Validación: Se realizan al acabar las pruebas de

integración, cuando ya se ha compuesto el software como sistema y
se han corregido los errores de interfaz. Estas pruebas se concentran
en las acciones visibles para el usuario.

11
 Pruebas de Sistema: Estas pruebas están más allá del alcance del
proceso del software y no las realizan únicamente los ingenieros de
software. Se comprueba también el nivel de seguridad del sistema, se
hacen pruebas de resistencia que permiten saber cómo responderá el
sistema a situaciones anormales de recursos y pruebas de
recuperación y de rendimiento.

 Pruebas de Aceptación: El usuario lo prueba en su propio entorno y

nos dice si lo acepta tal y como está o no.

12
 REFERENCIAS ELECTRÓNICAS

Cillero, Manuel. Diagramas de Paquetes. [Documento en línea]. Consultado

el 26 de Marzo del 2018 en: https://manuel.cillero.es/doc/metrica-
3/tecnicas/diagrama-de-paquetes/

Gutierrez, Demián. (2009). UML Diagramas de Paquetes (UML ilustrado).

[PDF en línea]. Consultado el 26 de Marzo del 2018 en:
http://www.codecompiling.net/files/slides/UML_clase_05_UML_paquetes.pdf

Montes de Oca, Raquel. (2015). Tema 09: Diagramas de Paquetes y de

Secuencias. [Documento en línea]. Consultado el 27 de Marzo del 2018 en:
http://jraquelm2.wixsite.com/ingenieriadesoftware/single-post/2015/07/08/-
TEMA-9-DIAGRAMAS-DE-PAQUETES-Y-DE-SECUENCIAS

González, Juan. ¿Qué es una versión Beta? [Documento en línea].

Consultado el 27 de Marzo del 2018 en: https://techlandia.com/version-beta-
hechos_256284/

Pérez, Julián y Gardey, Ana. (2010). Definición de manual de usuario.

[Documento en línea]. Consultado el 27 de Marzo del 2018 en:
https://definicion.de/manual-de-usuario/

Cervantes, Humberto. Evaluación de la Arquitectura de Software.

[Documento en línea]. Consultado el 28 de Marzo del 2018 en:
https://sg.com.mx/revista/31/arquitectura-evaluacion-la-arquitectura-software

Sosa, Raquel y Rienzi, Bruno. Introducción a los Sistemas de Información,

Arquitectura de Software, Integración de Sistemas y Middleware. [PDF en

13
línea]. Consultado el 28 de Marzo del 2018 en:
http://campusvirtual.edu.uy/libro1/capitulo7.pdf

Gestión de Riesgos en Ingeniería del Software. [Documento en línea].

Consultado el 29 de Marzo del 2018 en:
http://dis.um.es/~barzana/Informatica/IAGP/IAGP_riesgos.html

Hernández, María de Lourdes y Fernández, Juan. (2012). Evaluación de

algunos artefactos aplicados en el proceso de desarrollo de software de un
sistema específico. [PDF en línea]. Consultado el 29 de Marzo del 2018 en:
https://www.uv.mx/mis/files/2012/11/HernandezRodriguezFernandezPena.pdf

González, Daniel. (2016). Importancia de las pruebas en desarrollo de

software. [Documento en línea]. Consultado el 26 de Marzo del 2018 en:
https://www.yunbitsoftware.com/blog/2016/09/02/importancia-de-las-pruebas-
en-desarrollo-de-software/

14