1. Republica Bolivariana de Venezuela
Ministerios del Poder Popular para la Educación
Instituto Universitario Politécnico Santiago Marino
Cabimas - Zulia
Diseño orientado a
objetos
Integrante:
Alejandro Soto
C.I.: V.- 24.485.288

2. Para desarrollar un software de calidad es necesario
realizar una especificación completa de los requerimientos,
también es de suma importancia el empleo de técnicas y de
estándares definidos. No es de menos importancias las
metodologías de pruebas que se le realicen al producto, así a su
vez como el mantenimiento del mismo para ajustarlo a las nuevas
necesidades o solucionar sus propios defectos.
En la presente presentación se tratara de profundizar en
las normas, técnicas de pruebas, diseño de requerimientos que se
necesitan y el mantenimiento del software que son importantes
con las cuales nos ayudara a realizar estas actividades de una
mas eficiente y efectiva.
Introducción

3. Esquema
• Fundamento del diseño de Software
• Fundamento del diseño. Diseño orientado a objeto.
• Garantías de calidad del Software.
• Técnicas de pruebas de software.
• Mantenimiento de software Fundamentos al
requerimiento del diseño: especificaciones, principios.
• Métodos de análisis de requerimientos.

4. Fundamento del diseño.
Diseño orientado a objeto.
Según Peter Wegner, Un diseño basado en objetos es
aquel que usa tipos de datos abstractos. Un diseño orientado a
objetos es aquel que usa herencia y polimorfismo. La herencia
es la transmisión del código entre unas clases y otras.
Para soportar un mecanismo de herencia tenemos dos
clases: la clase padre y la/s clase/s hija/s. La clase padre es la
que transmite su código a las clases hijas. En muchos lenguajes
de programación se declara la herencia con la palabra "extends".

5. Garantías de calidad
del Software (SQA).
Consiste en los medios de la supervisión tecnología de
dotación lógica los procesos y los métodos aseguraban calidad.
Hace esto por medio de intervenciones de sistema de gerencia de
la calidad debajo de cuál se crea el sistema de software.
Estas intervenciones son movidas hacia
atrás por unos o más estándares,
generalmente ISO 9000. La calidad del
software es el conjunto de cualidades
que lo caracterizan y que determinan su
utilidad y existencia.

6. La calidad es sinónimo de eficiencia, flexibilidad,
corrección, confiabilidad, mantenibilidad, portabilidad,
usabilidad, seguridad e integridad. La calidad del software es
medible y varía de un sistema a otro o de un programa a otro.
Garantías de calidad
del Software (SQA).
“La calidad del software es el grado con
el que un sistema, componente o
proceso cumple los requerimientos
especificados y las necesidades o
expectativas del cliente o usuario”.

7. Técnicas de pruebas de
software.
Algunas de las técnicas más comunes de prueba de
software, de acuerdo con los criterios de clasificación más usuales
son las siguientes:
Composición Interna del Componente.
Esto se refiere al nivel de conocimiento de la estructura interna del
sistema a probar (SUT: System Under Testing), que el tester
requiere para realizar la prueba. Las técnicas comunes son:
Pruebas de caja negra (black-box
testing, o “pruebas de
funcionalidad”): centradas en
verificar si los requerimientos
son satisfechos.
Las pruebas de volumen y de
stress (rendimiento con grandes
cantidades de datos, y con
bloques de datos por unidad de
tiempo, respectivamente), son
casos especiales de este tipo de
prueba; otras técnicas son la de
clases de equivalencia y la de
valores límite.

8. Granularidad del Componente.
Se refiere al tamaño de los elementos del SUT que se van
probando. Las más comunes son:
Pruebas de unidad: se prueba por separado cada
“elemento mínimo de procesamiento” definido por la organización
(objetos, componentes, módulos, funciones). Las técnicas más
utilizadas son las de caja blanca. Típicamente, son realizadas por
el equipo desarrollador.
Pruebas de caja blanca (white-box testing, o
pruebas “de código/diseño”): se revisan,
entre otras cosas, el diseño y código fuente
para verificar que sigan los estándares
especificados, los algoritmos sean
adecuados, y la arquitectura sea apropiada.
Técnicas comunes son el análisis de
algoritmos, la cobertura de decisiones, las
revisiones entre pares y las recorridas.

9. Técnicas de pruebas de
software.
Pruebas de integración.
se verifica la interacción
entre unidades con técnicas
como pruebas de interacción
y de mutación. Suelen ser
ejecutadas por el equipo de
prueba.
Pruebas de sistema.
se verifica el sistema como
un todo, aplicando pruebas
de caja negra utilizando
perfiles de usuario, haciendo
v.gr. pruebas como
configuración, seguridad,
confiabilidad y recuperación.
Debieran ser ejecutadas por
el equipo de prueba.
Pruebas de aceptación.
se verifica la satisfacción de
requerimientos con técnicas
como pruebas-α y pruebas-β,
descritas más abajo.
Debieran ser llevadas a cabo
por un equipo que incluya al
cliente, usuario(s) y testers.

10. Mantenimiento de software
(preventivo, seguridad).
El mantenimiento preventivo de software es el proceso
por el cual se mejora y optimiza el software que se ha instalado,
este mantenimiento se realiza para la prevención de posibles
problemas que puedan llegar a surgir a medida que se utiliza el
computador.
La principal razón por la que se realiza este
mantenimiento es para evitar inestabilidad en el sistema, bajas
en el rendimiento del computador, perdida de productividad,
cortes en los sistemas y probables errores en el mismo. La
seguridad en el mantenimiento de software es el proceso
continuo que busca corregir fallas de seguridad (bugs, backdoor,
etc.) originada en el diseño. Para ello se desarrollan
actualizaciones que eliminan las vulnerabilidades.

11. Fundamentos al requerimiento del
diseño: especificaciones, principios.
Para poder definir un requerimiento este deberá ser verificable,
claro, trazable, modificable, alcanzable, etc. Mientras estos
principios se cumplan podemos decir que la definición es
completamente acertada y correcta.
Según la IEEE (830) “genera beneficios como base de
acuerdos con el cliente, reducción de esfuerzos de desarrollo,
estimación más acertada de costos y tiempos, mejora entre la
comunicación entre equipos, mejora de la calidad del software
y un proceso de validación y verificación confiable”.
Una buena definición, especificación y administración de
requerimientos es la base para dar paso a la siguiente etapa
que tiene que ver con el modelado del diseño lo que llamamos
diseño de software. Las etapas futuras depende de lo
planteado anteriormente.

12. Una especificación de
requisitos del software
es una descripción
completa del
comportamiento del
sistema a desarrollar.
Incluye un conjunto
de casos de uso que
describen todas las
interacciones que se
prevén que los
usuarios tendrán con
el software.
También contiene
requisitos no
funcionales (o
suplementarios). Los
requisitos no
funcionales son los
requisitos que
imponen restricciones
al diseño o
funcionamiento del
sistema (tal como
requisitos de
funcionamiento,
estándares de calidad,
o requisitos del
diseño).
Las estrategias
recomendadas para la
especificación de los
requisitos de software
están descritas por el
estándar IEEE 830 -
1998. Este estándar
describe las
estructuras posibles,
contenido deseable y
calidades de una
especificación de
requisitos del
software.

13. Métodos de análisis de
requerimientos.
Existe un gran número de técnicas para obtener requerimientos. A
continuación se enuncian las más utilizadas. Hay que aclarar que ninguna
de estas técnicas es suficiente por sí sola y que es recomendable
combinarlas para obtener requerimientos completos.
Entrevistas
Desarrollo Conjunto de Aplicaciones ( JAD )
Desarrollo de Prototipos
Observaciones
Cuestionarios
Tormentas de ideas
Implementación Efectiva de Sistemas Informáticos
desde los puntos de vista ( Humano y Técnico
Puntos de vista
Escenarios
Etnografía

14. Una estrategia de cómo aplicar estas técnicas dentro de un proceso ordenado
y que aproveche al máximo cada técnica, que evitará que los analistas con
poca experiencia caigan en un error muy común, que es el de pasar
demasiado pronto a las entrevistas, lo cual consideran es un desperdicio de
tiempo.
Los pasos de la estrategia sugerida son:
Aprender todo lo que se pueda
de los documentos,
formularios, informes y
archivos existentes. Es
sorprendente lo que se puede
aprender de un sistema sin
necesidad de quitarle tiempo
a la gente.
De ser posible, se
observará el sistema en
acción. No se plantearán
preguntas. Tan sólo se
observará y se tomarán
notas o dibujos.
Conviene asegurarse de
que las personas
observadas saben que no
se les está evaluando. En
caso contrario, harán su
trabajo de manera más
eficaz que lo normal.
Diseñar y distribuir
cuestionarios para
aclarar cuestiones que
no se comprenden
bien. Será también
buen momento para
solicitar opiniones
sobre los problemas y
las limitaciones. Los
cuestionarios
requieren que los
usuarios inviertan una
parte de su tiempo.
Pero son ellos los que
pueden elegir cuándo
les viene mejor
hacerlo.

15. Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se ha
recogido una base de requerimientos iniciales en los pasos anteriores, se pueden
utilizar las entrevistas para verificar y aclarar las cuestiones y los problemas de
mayor dificultad.
En este punto se pueden llegar a aplicar algunas de las otras técnicas cómo
Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo de
Prototipos.
• Se verifican los requerimientos a través del uso de técnicas como Entrevistas,
Observación y orientados a Puntos de Vista. Esta estrategia no es intocable.
Aunque habría que desarrollar una estrategia de investigación de hechos para
todas las fases pertinentes del desarrollo de sistemas, cada proyecto tiene sus
propias particularidades. A veces, la observación
Los cuestionarios pueden no ser apropiados. Pero debería mantenerse la idea de
recabar siempre todos los hechos que sea posible antes de concertar entrevistas.

16. Conclusión
Los metodología de requerimientos utilizan un conjunto
de técnicas y procedimientos para poder definir un software. •
Para tener calidad en el desarrollo del software se deben aplicar
las normas definidas en la ISO o IEEE.
El mantenimiento preventivo de software nos permite
mejora y optimizar el software.
Las técnicas de prueba nos ayudan a que el software
desarrollado tenga los estándares especificados y la arquitectura
sea apropiada.
El diseño de software nos permite definir y formalizar la
estructura del sistema con el suficiente detalle como para
permitir su realización física.
Un diseño basado en objetos es aquel que usa tipos de datos
abstractos.

17. Bibliografía
• (Oct. 18, 2010). Ingeniería del Software. Abr. 6, 2018, de blogspot.com Sitio
web: http://arielvargasu.blogspot.com/2010/10/garantia-de-calidad-de-
software-sqa_18.html
• Wayne Haythorn. (1994). Que es el diseño orientado a objetos. Abr. 6, 2018,
de Journal of Object Oriented Programming Sitio web:
http://www.ie.inf.uc3m.es/grupo/docencia/reglada/Is1y2/IS2/Haythorn.
pdf
• Roberto Hernández. (Abr. 14, 2016). Principios, metodologías y directrices
en el análisis y diseño de software. Abr. 6, 2018, de es.linkedin.com Sitio
web: https://es.linkedin.com/pulse/principios- metodolog%C3%ADas-y-
directrices-en-el-an%C3%A1lisis-dise%C3%B1o- roberto
• César Arturo Guerra. (S. F.). Obtención de Requerimientos. Técnicas y
Estrategia . Abr. 6, 2018, de Software Guru Sitio web:
https://sg.com.mx/revista/17/obtencion-requerimientos-tecnicas-y-
estrategia

18. • Anónimo. (May. 19, 2011). Especificaciones de requerimiento,
características y limitaciones del software. Abr. 6, 2018, de INGENIERIA
DE SOFTWARE Sitio web:
https://mundokramer.wordpress.com/2011/05/19/requerimientos-
caracteristicas-y-limitaciones-del-software/
• Anónimo. (Nov. 9, 2011). MANTENIMIENTO PREVENTIVO DEL
SOFTWARE . Abr. 6, 2018, de over-blog.com Sitio web:
http://informacione13.over-blog.com/article-mantwnimiwnto-
preventivo-del-software-88394816.html
• Anónimo. (2008). Caracterización de la Prueba de Software. Clasificación
y Técnicas. Abr. 6, 2018, de Software Guru Sitio web:
https://sg.com.mx/content/view/535
• Miguel Ángel Álvarez. (May. 20, 2014). Polimorfismo en Programación
Orientada a Objetos. Abr. 6, 2018, de desarrolloweb.com Sitio web:
https://desarrolloweb.com/articulos/polimorfismo-programacion-
orientada- objetos-concepto.html
• Miguel Ángel Álvarez. (Abr. 10, 2014). Herencia en Programación
Orientada a Objetos. Abr. 6, 2018, de desarrolloweb.com Sitio web:
https://desarrolloweb.com/articulos/herencia-en-programacion-
orientada- objetos.html