República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Superior

I.U.P. Santiago Mariño

Sede Barcelona Edo- Anzoátegui

Escuela de Ing. Sistemas

Sección: “S1”

Profesor: Bachiller:

José Castillo Cristian López

CI: 25.250.660.

Julio, 2019
 Introducción

La ingeniería de software implica seguir en cualquier proyecto de software

una metodología de desarrollo y la utilización de distintas técnicas y herramientas.
Los diferentes procedimientos a seguir en cualquier proyecto de ingeniería de
software.

El diseño orientado a objetos es la disciplina que define los objetos y sus

interacciones para resolver un problema de negocio que fue identificado y
documentado durante el análisis orientado a objetos.

El diseño Orientado a Objetos (DOO) difiere considerablemente del diseño

estructurado ya que en DOO no se realiza un problema en términos de tareas
(subrutinas) ni en términos de datos, sino que se analiza el problema como un
sistema de objetos que interactúan entre sí.
  Concepto del diseño orientado objetos.

El diseño orientado a objetos (DOO) crea una representación del problema del
mundo real y la hace corresponder con el ámbito de la solución, que es el software.
El análisis orientado a objetos, el diseño orientado a objetos y la programación
orientada a objetos comprenden un conjunto de actividades de la ingeniería del
software para la construcción de un sistema basado en objetos.

 Garantías aplicadas a la calidad ISO.

La norma ISO 9001 les otorga a las empresas un valor de garantía, el cual les ayuda
mantener e incrementar sus ganancias y su lista de clientes satisfechos. La calidad
siempre ha sido uno de los factores más relevantes en el sector de negocios, ya
que involucra a proveedores, empresarios y clientes; ahora no sólo se limita al
producto o al servicio, sino que comprende cada etapa del proceso de producción
en las que se garantiza la aprobación de lo que se quiere ofertar.

 Prueba de Software y sus aplicaciones.

Las pruebas de software son las investigaciones empíricas y técnicas cuyo objetivo
es proporcionar información objetiva e independiente sobre la calidad del producto
a la parte interesada o stakeholder. Es una actividad más en el proceso de control
de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de

software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen
distintos modelos de desarrollo de software, así como modelos de pruebas. A cada
uno corresponde un nivel distinto de involucramiento en las actividades de
desarrollo.

 Mejoramiento y mantenimiento.
 El mejoramiento significa la transformación o cambio que lleva a un sistema
más cerca del estándar o de la condición de operación normal, lleva la connotación
de que el diseño está definido y que se han establecido las normas para su
operación. El mejoramiento de los sistemas se refiere al proceso de asegurar que
un sistema opere de acuerdo a las expectativas, el mejoramiento es una
metodología que consta de los siguientes pasos:

1. Se define el problema e identifican el sistema y subsistemas componentes.

2. Los estados, condiciones o conductas se determinan mediante observación.
3. Se comparan las condiciones reales y esperadas a fin de determinar el grado
de desviación.
4. Se hipotetizan las razones de esta desviación de acuerdo con los límites de
los subsistemas componentes.
5. Se sacan conclusiones de los hechos conocidos, mediante un proceso de
deducción y se desintegra el gran problema en subproblemas mediante un
proceso de reducción.

El mantenimiento es la modificación de un producto después de su entrega al cliente

o usuario para corregir los defectos, para mejorar el rendimiento u otras propiedades
deseables, o para adaptarlo a un cambio de entorno.

El cambio es inevitable en la vida del software. Por ello, debemos desarrollar

mecanismos de evaluación, control e implementación de modificaciones.

Es el proceso general de cambiar un sistema después de que este ha sido

implantado. La estructura de organización necesita flexibilidad para apoyar el
mantenimiento de los sistemas existentes concurrentemente con la ejecución de
nuevas tecnologías

 Fundamento de análisis de requerimiento.

Es el conjunto de técnicas y procedimientos que nos permiten conocer los

elementos necesarios para definir un proyecto de software. Es la etapa más crucial
del desarrollo de un proyecto de software. La IEEE los divide en funcionales y no
funcionales:

 Funcionales: Condición o capacidad de un sistema requerida por el usuario

para resolver un problema o alcanzar un objetivo.
 No Funcionales: Condición o capacidad que debe poseer un sistema par
satisfacer un contrato, un estándar, una especificación u otro documento
formalmente impuesto.

Para realizar bien el desarrollo de software es esencial realizar una

especificación completa de los requerimientos de los mismos. Independientemente
de lo bien diseñado o codificado que esté, un programa pobremente especificado
decepcionará al usuario y hará fracasar el desarrollo.

La tarea de análisis de los requerimientos es un proceso de descubrimiento

y refinamiento, El ámbito del programa, establecido inicialmente durante la
ingeniería del sistema, es refinado en detalle. Se analizan y asignan a los distintos
elementos de los programas las soluciones alternativas.

Tanto el que desarrolla el software como el cliente tienen un papel activo en

la especificación de requerimientos. El cliente intenta reformular su concepto, algo
nebuloso, de la función y comportamiento de los programas en detalles concretos,
El que desarrolla el software actúa como interrogador, consultor y el que resuelve
los problemas.

Evaluación

Evaluación es el proceso de integración mediante el cual una persona juzga

o emite un juicio de valor acerca de un objeto, hecho o situación. En casi todas las
cosas realizadas a lo largo de nuestra vida tenemos que opinar, expresar nuestras
preferencias o rechazos, todos estos actos requieren una evaluación previa, aun
cuando no estemos conscientes de ello.
 Para evaluar se necesita analizar y tener un conjunto de criterios que sirvan
de base para emitir los juicios de valor.

Procedimiento para Evaluar.

1. Define el propósito para la evaluación.

2. Describe la situación deseada o ideal.
3. Define los criterios de comparación o de evaluación.
4. Describe el objeto o situación a evaluar, tal como se observa en la realidad.
5. Compara la situación deseada y la evaluada, tomando en cuenta criterios.
6. Identifica conformidades y discrepancias y emite juicios de valor.
7. Verifica el proceso y el producto.

Síntesis

Proceso mediante el cual se integran las partes, las propiedades y las

relaciones de un conjunto delimitado para formar un todo significativo.

Tipos de Síntesis

1. Cerrada: El autor solo puede incorporar las partes, elementos o relaciones

que dispone para elaborar el producto final.
2. Abierta: Puede incorporar conceptos, inferencias o suposiciones de sus
proia creación para buscar lo que se propone.

 Especificaciones.

Especificar quiere decir mencionar algo concreto, aclarar una información

que se ha facilitado con anterioridad. Y una especificación es una explicación
detallada. De esta manera, el concepto que analizamos implica que algo general
solamente puede entenderse con precisión si se describen todos los elementos que
lo conforman. Las especificaciones deberán permitir el rápido entendimiento de los
objetivos para que el contratista pueda entender el propósito del proyecto.
 La especificación de requisitos de software (ERS) es una descripción
completa del comportamiento del sistema que se va a desarrollar. Incluye un
conjunto de casos de uso que describe todas las interacciones que tendrán los
usuarios con el software. Los casos de uso también son conocidos como requisitos
funcionales. Además de los casos de uso, la ERS también contiene requisitos no
funcionales (complementarios). Los requisitos no funcionales son requisitos que
imponen restricciones en el diseño o la implementación, como, por ejemplo,
restricciones en el diseño o estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje

utilizado para su redacción debe ser informal, de forma que sea fácilmente
comprensible para todas las partes involucradas en el desarrollo.

 Soporte de abstracción.

Una abstracción se enfoca en la visión externa de un objeto, separa el

comportamiento específico de un objeto, a esta división que realiza se le conoce
como la barrera de abstracción, la cual se consigue aplicando el principio de mínimo
compromiso.

La abstracción encarada desde el punto de vista de la programación

orientada a objetos expresa las características esenciales de un objeto, las cuales
distinguen al objeto de los demás. Además de distinguir entre los objetos provee
límites conceptuales. Entonces se puede decir que la encapsulación separa las
características esenciales de las no esenciales dentro de un objeto. Hay una alta
gama de abstracciones que existen desde los objetos que modelan muy cerca de
entidades, a objetos que no tienen razón para existir, vamos a hacer una rápida
mención de ello.

1. Abstracción de Entidades: Es un objeto que representa un modelo útil de

una entidad que se desea.
2. Abstracción de Acciones: Un objeto que representa un conjunto de
operaciones y todas ellas desempeñan funciones del mismo tipo.
 3. Abstracción de Máquinas virtuales: Un objeto que agrupa operaciones,
todas ellas virtuales, utilizadas por algún nivel superior de control u
operaciones (entre ellos podríamos hablar de un circuito).
4. Abstracción de coincidencia: Un objeto que almacena un conjunto de
operaciones que no tienen relación entre sí.

 Definición de las pruebas de software.

Las pruebas de software consisten en la dinámica de la verificación del

comportamiento de un programa en un conjunto finito de casos de prueba,
debidamente seleccionados de por lo general infinitas ejecuciones de dominio,
contra la del comportamiento esperado. Son una serie de actividades que se
realizan con el propósito de encontrar los posibles fallos de implementación, calidad
o usabilidad de un programa u ordenador; probando el comportamiento del mismo.

 Pruebas como proceso

La prueba es un proceso que se enfoca sobre la lógica interna del software y las
funciones externas. Es un proceso de ejecución de un programa con la intención de
descubrir un error, no puede asegurar la ausencia de defectos; sólo puede
demostrar que existen defectos en el software.

 Objetivos de las pruebas de software.

La prueba de software es un elemento crítico para la garantía del correcto

funcionamiento del software. Entre sus objetivos están:

1. Detectar defectos en el software.

2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido antes
de entregar el software al cliente.
 5. Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes
clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los
principios básicos que guían las pruebas del software.

 Estrategia (caja negra).

Una caja negra es un elemento que se estudia desde el punto de vista de las
entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su
funcionamiento interno. En otras palabras, de una caja negra nos interesará su
forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que
también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar
importancia a cómo lo hace.

Estas pruebas permiten obtener un conjunto de condiciones de entrada que

ejerciten completamente todos los requisitos funcionales de un programa. En ellas
se ignora la estructura de control, concentrándose en los requisitos funcionales del
sistema y ejercitándolos.

La prueba de Caja Negra no es una alternativa a las técnicas de prueba de

la Caja Blanca, sino un enfoque complementario que intenta descubrir diferentes
tipos de errores a los encontrados en los métodos de la Caja Blanca. Muchos
autores consideran que estas pruebas permiten encontrar:

1. Funciones incorrectas o ausentes.

2. Errores de interfaz.
3. Errores en estructuras de datos o en accesos a las Bases de Datos externas.
4. Errores de rendimiento.
5. Errores de inicialización y terminación.

Para preparar los casos de pruebas hacen falta un número de datos que
ayuden a la ejecución de los estos casos y que permitan que el sistema se ejecute
en todas sus variantes, pueden ser datos válidos o inválidos para el programa según
si lo que se desea es hallar un error o probar una funcionalidad. Los datos se
escogen atendiendo a las especificaciones del problema, sin importar los detalles
internos del programa, a fin de verificar que el programa corra bien.

Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas
están:

1. Técnica de la Partición de Equivalencia: esta técnica divide el campo de

entrada en clases de datos que tienden a ejercitar determinadas funciones
del software.
2. Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del
programa para manejar datos que se encuentran en los límites aceptables.
3. Técnica de Grafos de Causa-Efecto: es una técnica que permite al encargado
de la prueba validar complejos conjuntos de acciones y condiciones.

 Estrategia (caja blanca).

Se denomina cajas blancas a un tipo de pruebas de software que se realiza

sobre las funciones internas de un módulo. Así como las pruebas de caja negra
ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca
están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la
cobertura de caminos, pruebas sobre las expresiones lógico-aritméticas, pruebas
de camino de datos, comprobación de bucles.

La prueba de caja blanca se basa en el diseño de casos de prueba que usa

la estructura de control del diseño procedimental para derivarlos. Las pruebas de
caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego
realizar las de caja negra sobre varios subsistemas (integración).

Mediante la prueba de la caja blanca el ingeniero del software puede obtener

casos de prueba que:
 1. Garanticen que se ejerciten por lo menos una vez todos los caminos
independientes de cada módulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.

Se considera a la prueba de Caja Blanca como uno de los tipos de pruebas

más importantes que se le aplican al software, logrando como resultado que
disminuya en un gran porciento el número de errores existentes en los sistemas y
por ende una mayor calidad y confiabilidad.

 Método de prueba.

Existen varios tipos de métodos de pruebas de integración. Las más

comunes son bottom-up, top-down y big bang.

Botton–Up: En el diseño bottom-up las partes individuales se diseñan con

detalle y luego se enlazan para formar componentes más grandes, que a su vez se
enlazan hasta que se forma el sistema completo. Las estrategias basadas en el flujo
de información "bottom-up" se antojan potencialmente necesarias y suficientes
porque se basan en el conocimiento de todas las variables que pueden afectar los
elementos del sistema.

Top-Down: En el modelo top-down se formula un resumen del sistema, sin

especificar detalles. Cada parte del sistema se refina diseñando con mayor detalle.
Cada parte nueva es entonces redefinida, cada vez con mayor detalle, hasta que la
especificación completa es lo suficientemente detallada para validar el modelo. El
modelo top-down se diseña con frecuencia con la ayuda de "cajas negras" que
hacen más fácil cumplir requisitos, aunque estas cajas negras no expliquen en
detalle los componentes individuales.

Las industrias de software se ven en constante perfeccionamiento de la

calidad de software logrando mejores resultados de la producción con la mayor
eficiencia. El objetivo de este trabajo es analizar la prueba de integración de Big
Bang con el propósito de validar su funcionalidad de acuerdo a la aplicación en
nuestro proyecto.

Existen muchas razones por las cuales un grupo de modulos que funcionan
correctamente de forma independiente no funcionen un ocasionen problemas al
trabajar juntos, entre las que podemos encontrar:

1. El acceso a estructuras de datos globales.

2. La duplicidad en nombres de variables.
3. La actualización de datos.
4. La no uniformidad en el diseño de la interfaz.

Big-Band:

La mejor forma de aplicar una prueba de integración, está aplicando un

enfoque incremental, es decir, ir integrando los módulos poco a poco, con lo cual
podemos aislar la detección de errores. Un enfoque no incremental como lo es el
enfoque “big bang”, consiste en integrar todos los módulos y una vez juntos probar
el sistema esperando la explosión de errores que se puede generar.

En big bang, se acoplan todos los módulos de una sola vez, reduciendo la
cantidad de pruebas.

La integración mediante el ensamblado de todos los componentes del

producto a la vez al final de las fases de diseño y construcción se llama “Integración
Big Bang”. Es muy difícil aislar las causas de los errores encontrados en las pruebas
si un producto se integra utilizando este enfoque. Además, la “Integración Big Bang”
no puede comenzar hasta un momento avanzado del proyecto porque requiere que
todos los módulos o sub-módulos del producto hayan sido desarrollados y probados
de forma unitaria.
  Tipos de prueba

Las pruebas de software son las comprobaciones que se efectúan sobre una
aplicación informática. Estas comprobaciones se realizan para aportar información
a los stakeholders sobre la calidad del producto.

Las pruebas de software pueden ser de dos tipos dependiendo si el código

de la aplicación es ejecutado o no.

 Prueba Dinámica.

Todas aquellas pruebas que para su ejecución requieren la ejecución de la

aplicación.

Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja

blanca con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de
pruebas es posible medir con mayor precisión el comportamiento de la aplicación
desarrollada.

En este apartado es donde recaen la mayoría de pruebas. Estos son algunos

ejemplos de pruebas dinámicas:

1. Pruebas de aceptación
2. Pruebas de regresión
3. Pruebas de integración
 Prueba Estática.

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Puede referirse a la revisión de documentos, ya que no se hace una

ejecución de código. Esto se debe a que se pueden realizar "pruebas de escritorio"
con el objetivo de seguir los flujos de la aplicación.
 Conclusión

El análisis orientado a objetos está interesado en el modelado del dominio de

aplicación y solución. Ambas actividades de modelado usan las mismas
representaciones (es decir, clases y objetos).

En el análisis y diseño orientados a objetos, el modelo del dominio de

aplicación también es parte del modelo del sistema.

En el diseño orientado a objetos, los objetos necesitan interactuar y

comunicarse, para realizar dicha comunicación, los objetos utilizan su propia interfaz
pública, dicha interfaz se compone principalmente de métodos y propiedades.

El diseño orientado a objetos transforma el modelo del análisis en un modelo

de diseño que sirve como anteproyecto para la construcción de software.
 Bibliografía

https://prezi.com/whnti0lpjqxz/diseno-orientado-a-los-objetos-o-doo/

https://visualmexico.com.mx/iso-9001-garantia-de-calidad/

https://es.wikipedia.org/wiki/Pruebas_de_software

http://samuelitosg.blogspot.com/2011/11/mejoramiento-de-sistemas-y-diseno-
de.html

https://www.edukativos.com/apuntes/archives/10657

https://www.definicionabc.com/general/especificacion.php

https://styde.net/abstraccion-programacion-orientada-a-objetos/

https://es.wikipedia.org/wiki/Abstracci%C3%B3n_(inform%C3%A1tica)

https://www.ecured.cu/Pruebas_de_software

https://es.wikipedia.org/wiki/Caja_negra_(sistemas)

https://www.ecured.cu/Pruebas_de_caja_negra

https://es.wikipedia.org/wiki/Caja_blanca_(sistemas)

https://www.ecured.cu/Pruebas_de_caja_blanca

https://es.wikipedia.org/wiki/Top-down_y_bottom-up

https://modelosdepruebasw.wordpress.com/

https://testermoderno.com/pruebas-estaticas-vs-pruebas-dinamicas/

https://es.wikipedia.org/wiki/Pruebas_de_software