FUNDAMENTO DEL DISEÑO DE SOFTWARE

1. REPUBLICA BOLIVARIANA DE VENEZUELA
INSTITUTO UNIVERSITARIO POLITECNICO
“SANTIAGO MARIÑO”
EXTENSION MARACAY
Autor:
Esteban Ortegón
C.I.: 26.192.490

3. Un sistema informático
está compuesto por
hardware y software.
En cuanto al hardware,
su producción se realiza
sistemáticamente y la
base de conocimiento
para el desarrollo de
dicha actividad está
claramente definida.
La fiabilidad del
hardware es, en
principio, equiparable a
la de cualquier otra
máquina construida por
el hombre.
Por su parte el
desarrollo del software,
al ser una herramienta
que pretende tener
aplicación dentro del
contexto de un
problema real, tiene que
seguir un proceso de
análisis y diseño que
proporcione los
cimientos bajo los
cuales se va desarrollar
la aplicación
conjuntamente.

5. Los fundamentos del diseño ayudan al desarrollador de software a responder a estas preguntas:
ƒ¿Qué criterios puedo utilizar para dividir el software en componentes
individuales?
ƒ¿Cómo se separan los detalles de una función o de la estructura
de los datos de la representación conceptual del software?
ƒ¿Existen criterios uniformes que definan la calidad técnica de un
diseño de software?

6. •Pueden formularse varios niveles de abstracción.
•En el nivel superior de abstracción se establece una solución en términos generales, en lenguaje natural.
•En los niveles inferiores de abstracción se utiliza una orientación más procedimental.
•Por último, en el nivel más bajo de abstracción, se establece una solución, de forma que pueda implementarse
directamente
1. ABSTRACCIÓN:
•Es una estrategia de diseño descendente.
•La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento de los detalles
procedimentales.
•Se desarrolla una jerarquía descomponiendo una función de forma sucesiva hasta que se llega a las sentencias
del lenguaje de programación.
2. REFINAMIENTO:
•El software se divide en componentes con nombres y ubicaciones determinados, que se denominan módulos y
que se integran para satisfacer los requisitos del proveedor.
3. MODULARIDAD:
•La arquitectura del software se obtiene mediante un proceso de partición, que relaciona los problemas del mundo
real (definidos en el análisis de requerimientos) con las soluciones software para resolver los problemas software.
4. ARQUITECTURA DEL SOFTWARE:

7. • Representa la organización jerárquica de los módulos de un programa e implica una jerarquía de
control.
• La representación de jerarquía se suele representar con diagramas de árbol, aunque también se
pueden utilizar otros tipos de notaciones.
5. JERARQUÍA DE CONTROL:
• Es una representación de la lógica que existe entre los elementos individuales de información.
• Debido a que la estructura de la información afectará de forma determinante al diseño procedimental, la
estructura de datos es tan importante como la estructura del programa en la representación de la
arquitectura del software.
6. ESTRUCTURA DE DATOS:
• Mientras que la estructura del programa define la jerarquía de control, independientemente de las
decisiones y secuencias de procesamiento.
• El procedimiento del software se centra en los detalles de procesamiento de cada módulo individual.
7. PROCEDIMIENTOS DEL SOFTWARE:
• El principio de ocultamiento de la información sugiere que los módulos deben especificarse de forma
que la información (procedimientos y datos) contenida dentro de un módulo sea inaccesible a otros
módulos que no necesiten tal información.
8. OCULTAMIENTO DE INFORMACIÓN:

9. El diseño orientado a objetos más conocido como DOO, transforma el modelo de análisis
creado, usando análisis orientado a objetos. El DOO requiere la definición de:
Una arquitectura multicapa.
La especificación de subsistemas que realizan
funciones y proveen soporte de infraestructura.
Una descripción de objetos (clases).
Una descripción de los mecanismos de
comunicación.
Es importante porque,
establece un anteproyecto de
diseño, el cual hace que se
maximice la reutilización de
este.

10. DISEÑO PARA SISTEMAS ORIENTADOS A OBJETOS
Se divide en 4 capas:
La Capa
Subsistema:
• Contiene una representación de cada uno de los
subsistemas, para conseguir sus requisitos definidos por
el cliente.
La Capa De Clases
Y Objetos:
• Contiene la jerarquía de clases, que permite al sistema
ser creado usando generalizaciones y con
especificaciones mas acertadas.
La Capa De
Mensaje:
• Contiene detalles de diseño, que permite a cada objeto
comunicarse son sus colaboradores.
La Capa De
Responsabilidades:
• Contiene estructuras de datos y diseños algorítmicos,
para todos los atributos y operaciones de cada objeto.

12. La calidad del software se define como:
Concordancia Con
Los Requisitos
Funcionales
Y De Rendimiento
Explícitamente
Establecidos,
Con Los
Estándares De
Desarrollo
Explícitamente
Documentados,
Y Con Las
Características
Implícitas
Que Se Espera De
Todo Software
Desarrollado
Profesionalmente.

13. La garantía de calidad del software se define como:
Consiste En La Auditoría
Y Las
Funciones
De Información
De La Gestión.
El Objetivo De
La Garantía De
Calidad
Es
Proporcionar
La Gestión
Para Informar
De Los Datos
Necesarios
Sobre La
Calidad Del
Producto,
Por Lo Que Se
Va Adquiriendo
Una Visión Más
Profunda
Y Segura De
Que La Calidad
Del Producto
Está
Cumpliendo
Sus Objetivos.

14. Tres puntos importantes:
1. Los requisitos del software son la
base de las medidas de la calidad. La
falta de concordancia con los
requisitos es una falta de calidad.
2. Los estándares especificados
definen un conjunto de criterios de
desarrollo que guían la forma en que
se aplica la ingeniería del software. Si
no se siguen esos criterios, casi
siempre habrá falta de calidad.
3. Existe un conjunto de requisitos
implícitos que a menudo no se
mencionan (por ejemplo: el deseo por
facilitar el uso y un buen
mantenimiento). Si el software se
ajusta a sus requisitos explícitos pero
falla en alcanzar los requisitos
implícitos, la calidad del software
queda en entredicho.

16. 1. Prueba Unitaria
•La prueba unitaria se aplica en el elemento más pequeño de un sistema, cada componente es testeado para asegurar que
funciona correctamente.
•Normalmente desarrolla una única función cohesiva.
•La función de la prueba unitaria es de analizar cada pequeña parte y testear que funciona correctamente.
2. Pruebas De Integración
•La prueba de integración es una extensión lógica de las pruebas unitarias.
•Dos unidades que ya han sido testeadas y combinadas en un componente y su interface son testeadas entre ellas.
•El motivo de las pruebas de integración es de verificar la funcionalidad y la seguridad entre los componentes que han sido
integrados.
•Identifica los problemas que ocurren cuando las unidades se combinan.
3. Pruebas Funcionales
•Las pruebas funcionales se basan en asegurarse de que todas las características funcionen de cabo a rabo.
•Las pruebas funcionales testean una pequeña parte de la funcionalidad del sistema entera.
•Se aplica para verificar que las aplicaciones y funcionalidades del software actuan correctamente acorde a un diseño específico.
•Las pruebas funcionales son elementos cruciales para asegurar la calidad del producto software y confirmar que actúa acorde a
sus funciones tal y como el usuario espera.
4. Pruebas De Rendimiento
•La prueba de rendimiento es una práctica de test que determina la actuación de un sistema en términos de respuesta y
estabilidad en una carga de trabajo en particular.
•También puede servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como la escalabilidad,
seguridad y uso de recursos.
•Las pruebas de rendimiento construye unos estándares de actuación en la implementación, diseño y arquitectura de un sistema.

18. Proceso Por El Cual Se Mejora Y Optimiza
El SoftwareInstalado,
Este
Mantenimiento
Se Realiza
Para
La Prevención
De
Posibles
Problemas
Que Puedan
Llegar A Surgir
A Medida Que
Se Utiliza

19. Seguridad del software
La seguridad del software es
una actividad de garantía de
calidad del software que se
centra en la identificación y
evaluación de los riesgos
potenciales que pueden
producir un impacto negativo en
el software y hacer que falle el
sistema completo.
Si se pueden identificar pronto
los riesgos en el proceso de
ingeniería del software podrán
especificarse las características
del diseño del software que
permitan eliminar o controlar los
riesgos potenciales.

21. 1.- Descomposición funcional
La descomposición funcional se
refiere al proceso de identificar y
resolver las relaciones funcionales
en sus partes constituyentes, de tal
forma que la función global pueda
ser reconstruida a partir de sus
partes.
Por lo general, la descomposición
funcional se realiza para identificar y
entender los componentes o partes
que constituyen un todo (o función
global).
En este proceso, es vital identificar
las interacciones entre
componentes.
Aplicado a la Ingeniería de
requisitos, consiste en tomar los
requerimientos de software,
dividirlos en partes y analizarlos
individualmente. De ser necesario,
se pueden descomponer en más
partes hasta lograr un nivel
adecuado de detalle.
En cierto sentido, el proceso es
similar al de la elaboración de una
estructura de desglose de trabajo de
un proyecto.
En Ingeniería de sistemas, la
descomposición funcional consiste
en definir un sistema en términos
funcionales, para luego definir
funciones de más bajo nivel y
establecer las relaciones con estas
funciones de alto nivel.
La intención es dividir un sistema de
tal forma que cada componente se
pueda describir sin necesidad de
referir a otro componente.
De esta forma, cada parte del
sistema tendrá funciones
independientes, que pueden
reusarse y reemplazarse.

22. 2.- Especificación vía Sentencias Textuales
Es la forma tradicional de la especificación de requerimientos de software.
Se usan especificaciones textuales en lenguaje natural, que se documentan en
matrices de trazabilidad de requerimientos o definiciones del alcance.
El procedimiento consiste en tomar el requerimiento producto del levantamiento de
información, para desarrollar una narrativa más detallada.
No usa herramientas visuales como los flujogramas o estructura como los casos de uso,
es simplemente una descripción más detallada del requerimiento en lenguaje natural.

23. 3.- Modelado del proceso
Comprende la elaboración de diagramas de flujo de procesos (Flujogramas) a partir de los requerimientos
del software.
Existen diversas herramientas de modelado de procesos, cada una de las cuales posee sus propios
símbolos y reglas.
Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y departamentos
intervinientes.
Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas, manuales o
combinación entre ambas.
Su naturaleza visual ayuda a la comprensión y comunicación a terceros.
Cuando los procesos son complejos, deben desglosarse en componentes (subprocesos).
La relación entre los diagramas de flujo y la gerencia de proyectos es fundamental para el éxito.

24. En Ingeniería de software, en análisis de
dominio consiste en analizar sistemas o
software relacionados en un dominio, con
la finalidad de encontrar sus partes
comunes y partes que los diferencian.
Produce un modelo de contexto de
negocio para todo el sistema.
Un modelo de dominio comprende
diagramas conceptuales que incluyen
tanto el comportamiento de un sistema
como sus datos.
Un tipo de modelo de dominio son los
diagramas de funcionalidades (Features
Diagrams), que es una representación
“compacta” del sistema o aplicación en
términos de sus características.
El análisis de dominio produce modelos
orientados a objetos o modelos
relacionales de datos, que pueden ser
usados por los desarrolladores de
software como base de arquitecturas de
software y aplicaciones.
4.- Modelo de dominio

25. No son la mejor opción en sistemas sin usuarios, o dominados fundamentalmente por requerimientos no funcionales.
Son útiles en sistemas informáticos orientados a la funcionalidad (transacciones con el usuario), que se van a implementar
orientados a objetos y con UML.
Además de usarse para analizar los requerimientos de software, también pueden usarse en el diseño del sistema e inclusive
para definir pruebas de caja negra (Testing).
Formato simple y estructurado que puede ser compartido entre usuarios y desarrolladores.
En el ámbito académico y profesional, es una de las técnicas de mayor difusión para especificar el comportamiento del
Sistema.
En el Lenguaje de Modelado Unificado (UML), un caso de uso es una secuencia de interacciones entre un sistema y alguien o
algo que usa alguno de sus servicios.
5.- Casos de Uso

26. La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones que se
realizan sobre los requerimientos de software, que nos sean presentados de forma escrita.
Una lista de chequeo puede realizar preguntas como:
• ¿Se han especificado los requisitos de hardware y software?
• ¿Se han realizado consideraciones de seguridad?
• ¿El nivel de granularidad del requerimiento se ha incluido?
• ¿Se ha incluido el código de referencia en para identificar el requisito en el desglose de requerimientos?
• ¿Está escrito el requerimiento en un lenguaje claro y conciso?
• ¿El requerimiento es único? (no existe duplicidad con otro requerimiento).
• Y muchas preguntas más.
La lista de chequeo sirve de marco de trabajo y procedimental para revisar el requerimiento,
facilitando su análisis de forma estructurada.
Los requerimientos se pueden revisar sobre la matriz de trazabilidad de requerimientos o
sobre la definición del alcance.
6.- Checklists

27. Revisión no destructiva de los requerimientos de software. Por
ejemplo:
• Examinar un software visualmente para constatar que las pantallas solicitadas se
encuentran incluidas.
• Verificar la inclusión de los campos necesarios para el ingreso de datos.
• Verificar la existencia de los botones necesarios para iniciar la funcionalidad que ha sido
requerida.
• Verificar que el requerimiento se apega a los estándares definidos para la aplicación. Por
ejemplo estándares de navegación entre pantallas y estándares de interfaz gráfica.
De forma similar al uso de la lista de chequeo, la inspección consiste
en tomar el requerimiento definido en la matriz de trazabilidad o
definición de alcance, leerlo y producir un resultado para su corrección.
7.- Inspección

28. Consiste en elaborar representaciones visuales (interfaz gráfica con el usuario) de los requerimientos de
software.
Es una herramienta muy útil para validar con los usuarios, clientes e interesados de proyecto que el
diseño funcional corresponde con los requerimientos de software (Que existe entendimiento común
entre desarrolladores de software y usuarios).
Permite a desarrolladores y usuarios entender mejor los requerimientos, determinar cuáles son
indispensables y cuales deseables, e identificar riesgos de forma temprana.
Puede enfocarse en toda la solución o sólo en áreas específicas.
Puede extenderse innecesariamente en el tiempo si las discusiones se realizan en torno al como en
lugar de en torno al que.
La elaboración de prototipos conlleva iteraciones entre desarrolladores y usuarios, en los cuales se van
elaborando varios prototipos y sometidos a evaluación del cliente.
8.- Prototipos

30. Con el constante
desarrollo e innovación
de las tecnologías
utilizadas en las
implementaciones de
software, es deseable
tener un modelo no
dependiente de
mecanismos, métodos y
plataformas específicas,
adecuándolo a
necesidades y
ambientes particulares.
Si bien se han utilizado
conceptos de
paradigmas como el de
desarrollo orientado a
objetos o sistemas en
tiempo real, se ha
buscado generalizarse
para que su
interpretación pueda
hacerse según
condiciones singulares
de los problemas a
tratar.
La consideración de un
mecanismo para realizar
la gestión del riesgo
hace parte de los
principios técnicos para
el desarrollo de
proyectos de ingeniería.
A nivel de la Ingeniería
de software y del
modelo planteado, la
gestión actúa como
instrumento para el
control de calidad y
como guía para conocer
las limitaciones y
características del ciclo
de vida.

32. Anónimo. (2014) Fundamentos del diseño de software. [Pagina web en Línea] Disponible en:
https://cmapspublic.ihmc.us/rid=1LQ5KGY9H-J0CYGK-3GBN/FundamentosDiseno.pdf (Consulta: 2019, 06 de
Julio)
Cabrera, A. (2016) Diseño orientado a objetos. [Pagina web en Línea] Disponible en:
https://www.emagister.com/uploads_courses/Comunidad_Emagister_63082_63082.pdf (Consulta: 2019, 06 de
Julio)
Fernández, R. (2019) Garantía de la Calidad de Software. [Pagina web en Línea] Disponible en:
http://files.rfernandez.webnode.es/200000013-3f04e40f77/Resumen%20del%203%20parcial%20Cap%208-9-
19.pdf (Consulta: 2019, 06 de Julio)
Anónimo. (2019) Técnicas de testeo de software y herramientas. [Pagina web en Línea] Disponible en:
https://apiumhub.com/es/tech-blog-barcelona/tecnicas-de-testeo-de-software/ (Consulta: 2019, 06 de Julio)
Anónimo. (2011) Mantenimiento preventivo del software. [Pagina web en Línea] Disponible en:
http://informacione13.over-blog.com/article-mantwnimiwnto-preventivo-del-software-88394816.html (Consulta:
2019, 06 de Julio)