Principales fundamentos o principios para poder diseñar un software correctamente

1. REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA,
CIENCIA Y TECNOLOGÍA
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
EXTENSIÓN MATURÍN
FUNDAMENTOS BASICOS DEL
DISEÑO DE SOFTWARE
Profesor: Alumno:
Ing. Ángel Lugo Pedro Luces
C.I: 26.975.279
Maturín, Julio 2021

2. DISEÑO DE SOFTWARE
El diseño es definido en IEEE610.12 – 90 como tanto el proceso de definir la
arquitectura, la componentes, interfaces, y las otras características de un sistema o
componente como el resultado de eso se procesa. Visto como un proceso, el diseño de
software es la actividad de ciclo de vida de ingeniería de software en la que los
requerimientos de software son analizados para causar una descripción de la estructura
interna del software que servirá como base para su construcción. Más precisamente, un
diseño de software (el resultado) debe describir la arquitectura de software, es decir cómo
el software está en estado de descomposición y organizado en los componentes y las
interfaces entre esos componentes. También debe describir los componentes en un nivel
del detalle que permiten su construcción.
El diseño de software tiene un papel importante en el desarrollo de software, ya que
permite que ingenieros de software produzcan modelos distintos que moldean una clase
de plano de la solución a ser implementado. Podemos analizar y valorar a estos modelos
para determinar cuál de estos permitirá o no, cumplir con una gama de requerimientos.

3. IMPORTANCIA DEL DISEÑO DEL SOFTWARE
Una fase muy importante en el ciclo de vida de un proyecto es el Diseño del
Software. Se trata de una etapa fundamental y en muchas ocasiones la más importante
en el desarrollo de Software. Es el momento en que los profesionales tienen que aportar
sus conocimientos, experiencia y creatividad para llegar a una solución que cumpla con
los requerimientos funcionales y no funcionales establecidos en la fase de la toma de
requisitos.
El diseño del Software tiene un impacto directo sobre la capacidad del sistema para
cumplir o no el total de requerimientos establecidos. Un error de diseño en esta fase
puede acarrear problemas en todo el proyecto y provocar que este caiga en una espiral
de continuos cambios y de rehacer constantemente el trabajo.

4. ENTENDIMIENTO DE LOS REQUISITOS:
Debemos tener claros todos los requerimientos que afectan al Diseño del
Software. Estos pueden ser funcionales o no, pero deberán estar completamente
definidos, entendidos y documentados. Casi todos los problemas futuros comienzan
por no tener claros los requisitos. Estos deberán 100% claros y sin ambigüedades
PATRONES DE DISEÑO:
No deberíamos de inventar nada que ya esté inventado. Para ello debemos
conocer y aplicar los patrones de diseño. Estos son soluciones (ya probadas y
documentadas) a problemas de desarrollo conocidos.
CALIDAD:
La calidad del diseño deberá ir evaluándose mientras se va creando y no cuando
ya esté terminado.

5. MODULARIDAD:
El diseño deberá ser modular dividiéndose en estructuras que realicen funciones
específicas. Esto facilitará la reutilización. Además deberá realizarse de manera que
permita cambios y que permita la extensión de funcionalidades sin afectar a otras. Una
muy buena práctica para esto es exponer las funcionalidades a través de interfaces.
DISEÑOS AGILES:
No es necesario definir el diseño completo al inicio. Se puede partir de un diseño
general e ir construyéndolo a medida que avanza el desarrollo, de esta manera se
adaptará a cambios y evoluciones. Separar completamente el diseño de la codificación
tiene sus riesgos y siempre es mejor contar con profesionales que puedan diseñar y
codificar.

6. DOCUMENTACION:
Es fundamental poder comunicar el diseño a otras personas involucradas en el
desarrollo. La documentación se realiza por medio de distintas vistas de más alto o
bajo nivel. Estas vistas contienen normalmente diagramas además de información
que apoyan a su compresión. Como resumen podemos decir que para que el
desarrollo de software se realice con calidad, merece la pena esforzarse en un buen
Diseño del Software. El diseño es importante y deberá realizarse todos los días, esto
nos permitirá tener una visión general antes de lanzarse a la codificación y
construcción.
PRINCIPIOS BASADOS EN DISEÑO DE ATRIBUTOS DE CALIDAD:
Según M.A. Jackson (1975) “El comienzo de la sabiduría para un ingeniero de
software es reconocer la diferencia entre hacer que un programa funcione y
conseguir que lo haga del modo correcto”. El diseño de la arquitectura de software
es una fase muy importante en el ciclo de vida del software. Es absolutamente
necesario desempeñar ésta tarea con demasiada cautela, ya que un error en ésta fase
del desarrollo puede lastrar todo un proyecto y llevarlo a caer en una espiral
de constantes cambios. Existen algunas reglas las que podríamos considerar a la
hora de diseñar la arquitectura del sistema.

7. FUNCIONALIDAD:
Cada fragmento de software debe hacer la vida más fácil al usuario, la regla 80-
20 debe encajar aquí (por lo menos un 80 % del tiempo).
ORDEN:
Cada pieza de software debe estar organizada para encontrar fácilmente cada
fragmento de código, y estructurado de forma fácil para poder añadir un nuevo
fragmento.
TRAZABILIDAD:
Cada fragmento de software deberá registrar sus acciones en detalle,
preferentemente en diferentes niveles de detalles. Utilizar librerías de logging
facilitará tu trabajo.

8. SEGURIDAD:
Cada pieza de software no debe revelar sus debilidades de seguridad,
esto permitiría que se abusara maliciosamente del sistema, como inyección de código,
modificación de privilegios no autorizados, denegación de servicios del sistema, etc.
PORTABILIDAD:
Un software portable es mucho mejor que un software que necesitas instalar. Copiar
ficheros a un lugar es mucho más fácil que seguir un procedimiento de instalación.

9. REUSABILIDAD:
Cada fragmento de software debe ser lo más reutilizable posible (a menos que sea
aplicativo), y reutilizar otros componentes lo mayor posible.
Cuando desarrollas software, el factor de reusabilidad es crucial, especialmente
cuanto tienes plazos que cumplir. Divide tu código en varias librerías bien definidas,
que te permita utilizar en otros proyectos, por lo general te costará menos en
conceptos de tiempos, esfuerzo y dinero cuando varios proyectos están involucrados.
CUANDO NO REUTILIZAR:
Un caso donde no es bienvenida la reutilización es en un proceso muy específico.
Otro caso donde no se recomienda reutilizar, es la falta de entendimiento para
encontrar la forma correcta de construir código reutilizable. Por lo general, el código
en cuestión se escribió sólo una o dos veces.

10. EXTENSIBILIDAD:
Cada fragmento de software deberá ser lo más extensible posible, es decir, tener todos
los lugares posibles para añadir más funcionalidad. La extensibilidad te permite añadir
nuevas funcionalidades en el futuro. Existen muchos tipos de extensibilidad, tanto
internas como externas. Extensibilidades externas son las más importantes. El
desarrollador de software reutilizable deberá tener en cuenta la necesidad de otro
desarrollador para añadir funcionalidad o hacer las cosas un poco diferentes de su propio
punto de vista.
MEJORES PRACTICAS DE EXTENSIBILIDAD:
Una regla de oro de extensibilidad sería exponer la funcionalidad de siempre a través
de interfaces, y si desea que el usuario sea capaz de llevarlas a la introducción de los
objetos creados a tu librería, utilice el patrón de fábrica, y permitir al usuario el registro
de sus propios tipos.

11. ORDEN Y ESTRUCTURA:
Cuando desarrollas la estructura de tu proyecto, hazla significativamente separada
por la lógica, no en términos físicos. Piense en alguien que no conoce el proyecto y
necesita un fichero determinado, si no puede encontrarlo es que la estructura no sigue
una lógica determinada.
De la misma manera se pueden utilizar directivas de región. Si veo miles y miles de
métodos públicos, como podré encontrar lo que necesito realmente. Sería óptimo
separar las funcionalidades por región, considérese por el tipo de interacción con el
usuario, diseño de lógica, construcción e inicialización.

12. ESTRATEGIAS DE DISEÑO DE SOFTWARE:
Aquí se traducen los requisitos en una representación del software
realizándose en dos etapas:
Diseño preliminar: es la transformación de los requisitos en los datos y
arquitectura del software.
Diseño detallado: se ocupa del refinamiento y de la representación
arquitectónica que lleva una estructura de datos refinada y a las
representaciones algorítmicas del software.
ESTRUCTIRA DE DATOS:
Es una representación de la relación lógica existente entre los elementos
individuales de datos. Establece la organización, métodos de acceso, el grado
de asociatividad y las alternativas de procedimiento para la información.

13. PROCEDIMIENTO DEL SOFTWARE:
Se centra sobre los detalles de procesamiento de cada módulo individual. Debe
proporcionar una especificación precisa del procesamiento, incluyendo la secuencia
de sucesos, los puntos concretos de decisiones. Debe incluir referencias a todos los
módulos subordinados del módulo que describe.
OCULTAMIENTO DE LA INFORMACION:
Capacidad que obtienen los módulos de transmitir información contenida en
ellas pero solamente información necesaria. Implica que hay que definir un
conjunto de módulos independientes, que se comuniquen con los otros mediante la
información que sea necesaria para realizar la función del software.
Módulo secuenciales: ejecutan secuencialmente una tarea
Módulos incrementales: puede ser interrumpido antes de que terminen por el
software de la aplicación y restablece posteriormente su ejecución en el punto que
se interrumpió.
Módulo paralelo: se ejecuta a la vez que otro módulo en entorno
multiprocesadores.

14. ALGUNAS DESCRIPCIONES ESTRUCTURALES (VISTA ESTATICA):
Diagramas de clase y objeto: se usan para representar un conjunto de clase (y
objetos) y sus relaciones. Una notación antigua relacionada son los diagramas
entidad-relación usados para representar modelos conceptuales de datos
almacenados en sistemas de información.UML tiene esta notación
Diagramas de componentes: se usan para modelar la vista de implementación
estáticas de un sistema, es decir, cosas físicas (y sus relaciones) como ejecutables,
librerías, tablas, archivos y documentos. A pesar que si uso principal es durante la
construcción, estos diagramas pueden ser usados durante diseño, por ejemplo, para
documentar la estructura de un módulo.UML tiene esta notación
Cartas de estructuras o Diagrama de Estructura: se usan para describir la
estructura de llamado de un programa, es decir, cuál módulo es invocado por otro
módulo. Estos diagramas son inherentes de la aproximación de diseño orientado a
la función.

15. ALGUNAS DESCRIPCIONES CONDUCTUALES (VISTA DINAMICA)
Diagramas de actividad: se usan para mostrar el flujo de control de actividad
(ejecución continua no-atómica dentro de una máquina de estado) a otra actividad.
UML tiene esta notación.
Diagramas de interacción: se usan para mostrar las interacciones entre un grupo de
objetos. Estos diagramas vienen en dos tipos: diagramas de secuencia ponen el
énfasis en el ordenamiento temporal de los mensajes, mientras que los diagramas de
colaboración ponen el énfasis en los objetos, sus enlaces y los mensajes que
intercambian en estos enlaces. UML tiene esta notación.
Diagramas de flujo de datos: se usan para mostrar el flujo de datos entre un
conjunto de procesos.

16. !GRACIAS POR SU
ATENCION!