Este documento presenta una introducción a los fundamentos del diseño de software, incluyendo conceptos como la modularidad, la arquitectura de software, la jerarquía de control, la estructura de datos, los procedimientos de software y el diseño orientado a objetos. También cubre temas como la garantía de calidad de software, los métodos de prueba de software y el mantenimiento de software. Por último, describe varios métodos de análisis de requerimientos como la descomposición funcional y la especificación a través de declaraciones de texto.

1. Fundamentos del Diseño
de Software
ALUMNO: NELSON GUANIPA
C.I: 25,993,940
REPUBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DE PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA
INSTITUTO UNIVERSITARIO POLITÉCNICO SANTIAGO MARIÑO
BARCELONA EDO ANZOÁTEGUI

2. Introducción
A continuación el tema que se plantea pretende dar a conocer y repasar puntos referentes al diseño, desarrollo y
pruebas de Software, así como la obtención de sus requerimientos; para dar una idea mas clara de los procesos y
metodologías utilizadas en esta área y explicando un poco en que consiste cada una.
En el diseño de Software se llevan a cabo diferentes pasos para obtener un producto que cumpla con las
especificaciones deseadas ajustándose a los parámetros establecidos por las medidas de calidad y garantía,
además de establecerse sus ciclos de mantenimiento y afinaciones reglamentarias para garantizar su perfecto
funcionamiento

3. Fundamentos del Diseño de Software
Modularidad
Arquitectura del Software
Jerarquía de Control
Estructura de Datos
Procedimientos de Software

4. Modularidad
El software se divide en componentes con nombres
determinados que se denominan módulos. Un programa
compuesto de un solo módulo no puede ser fácilmente
manejado intelectualmente. Es más fácil resolver problemas
complejos cuando se descomponen en trozos más
manejables
Puede concluirse que si partiéramos el software indefinidamente el
esfuerzo para desarrollarlo sería insignificantemente pequeño. Sin
embargo existen otros factores que hacen inválida esta conclusión

5. Arquitectura de Software
La arquitectura del software se refiere a:
1.- La estructura jerárquica de los componentes procedimentales.
2.- La estructura de los datos.
La arquitectura del software se obtiene mediante un proceso de partición, que relaciona
los elementos de una solución de software con partes de un problema del mundo real
definido en el análisis de requisitos.

6. Arquitectura de Software
Usando alguna de las metodologías de diseño del software se producirá un determinado tipo de estructura del
software.

7. Jerarquía de Control
La jerarquía de control, también denominada “estructura del programa”, representa la organización de los
componentes del programa ( módulos ). Esto no representa aspectos procedimentales del software, tales como
la secuencia de procesos, la ocurrencia u orden de las decisiones o la repetición de operaciones.
Para representar la jerarquía de control lo más común es usar un diagrama en forma de árbol.

8. Estructura de Datos
La estructura de datos es una representación de la relación lógica existente entre los elementos individuales de
datos. Debido a que la estructura de la información afectará invariablemente al diseño procedimental final, la
estructura de datos es tan importante como la estructura del programa en la representación de la arquitectura
del software.
La estructura de datos dicta la organización, los métodos de acceso, y las alternativas de procesamiento para la
información.

9. Procedimientos de Software
El procedimiento del software se centra sobre los detalles de procesamiento de cada módulo individual. El
procedimiento debe proporcionar una especificación precisa del procesamiento, incluyendo la secuencia de
procesos, las decisiones y la repetición de operaciones. La representación procedimental del software se realiza por
capas.

10. Diseño Orientado a Objetos
El diseño orientado a objetos (DOO) es una fase de la metodología orientada a objetos para el desarrollo de
software.
Su uso induce a desarrolladores y programadores a pensar en términos de objetos, en vez de procedimientos,
cuando planifican el código.
Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La "interfaz del objeto",
esto es, las formas de interactuar con el objeto, también se definen en esta etapa.
Un programa orientado a objetos se caracteriza por la interacción de esos objetos.
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 (AOO).

11. Garantía de Calidad de 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.
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

12. •Un enfoque de gestión de calidad .
•Tecnología de Ingeniería de Software efectiva (métodos y
herramientas).
•Revisiones técnicas formales que se aplican durante el
proceso del software.
•Una estrategia de prueba multiescalada.
•Un control de la documentación del software y de los
cambios realizados
•Un procedimiento que asegure un ajuste a los estándares de
desarrollo de software.
•Mecanismos de medición y de generación de informes.
La SQA (Software QualityAssurance) engloba:

13. Métodos de Prueba de Software
La prueba del software es tanto un arte como una ciencia. En grande, los usos complejos, tales como sistemas
operativos. Diversos usos del software requieren diversos acercamientos cuando viene a la prueba, pero algunas
de las tareas mas comunes del QA del software incluyen:
Prueba deValidación
Es el acto de los datos que
entran que el probador sabe
para ser erróneo en un uso
Comparación de los Datos
Se compara la salida de un uso
con parámetros específicos a
un sistema previamente creado
de los datos con los mismos
parámetros que se saben para
ser exactos.

14. Prueba de laTensión
Es cuando el software se utiliza tan
pesadamente como sea posible
por un período de la hora de
considerar si hace frente a los altos
niveles de la carga.
Prueba de la Utilidad
Consiguiendo a los usuarios que
son desconocedores con el
software intentarlo durante algún
tiempo y ofrecer la regeneración a
los reveladores sobre lo que
encontraron difíciles de hacer es la
mejor manera de llevar a cabo
mejoras a un interfaz.

15. Mantenimiento de software
Es la modificación de un producto de software después de la entrega, para corregir errores, mejorar el
rendimiento, u otros atributos. El mantenimiento del software es una de las actividades más comunes en la
ingeniería de software.
El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas (SDLC,
sigla en inglés de system development life cycle), que se aplica al desarrollo de software. La fase de
mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.

16. El mantenimiento preventivo consiste en una atención constante de limpieza, revisión y afinación de los distintos
elementos integrantes de un equipo de cómputo. Es importante saber que la mayoría de los problemas que se
presentan en el trabajo cotidiano, se debe a la falta de un programa específico de mantenimiento de los equipos,
de tal manera que la mayoría de los problemas se resuelven con el mismo procedimiento del mantenimiento
preventivo.
El mantenimiento tiene técnicas para darle un periodo de vida útil más largo y libre de fallas. Debemos de tener
en cuenta que es necesario darle mantenimiento al software ya que el continuo uso genera una serie de cambios
en la configuración original del sistema, causando bajas en el rendimiento que al acumularse con el tiempo
pueden generar problemas serios. Actualmente es indispensable mantener actualizada la protección contra virus
informáticos.
Por supuesto es muy recomendable usar el equipo responsablemente, ya que esto le podrá causar un gasto
mayor a futuro.

17. Métodos de análisis de Requerimientos.
Descomposición funcional
Especificación vía SentenciasTextuales
Modelado del proceso
Modelo de dominio
Casos de Uso
Checklists
Inspección
Prototipos

18. 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.

19. Especificación vía SentenciasTextuales
• 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

20. Modelado del Proceso
• 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.
• 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.

21. Modelado del Dominio
• 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.

22. Casos de Uso
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.

23. Checklists
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.

24. Inspección
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.

25. Prototipos
• 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.

26. Conclusión
En el diseño de Software suelen tomarse en cuenta muchos factores, tales como sus objetivos funcionales, los
parámetros a seguir y los recursos con los q se debe interactuar dentro del entorno de desarrollo.
Esto tiene un impacto directo en el enfoque, estructura, utilidad y la optimización que pueda llegar a tener, a
través de esto se realizan diversas pruebas para comprobar si el software desarrollado cumple con los estándares
de calidad y garantía, ademas de establecer una conclusión mas firme y saber si cumplirá con su objetivo de
manera optima o necesitaría mas complementes y desarrollo.
Dentro de las diversas pruebas de software, se aprecia que son utilizadas de manera que los resultados sean
contundentes y claros, ya sea desde comprobar dato a dato hasta realizar una prueba de estrés a todo en
conjunto para saber si podrá con la tension exigida dentro del campo real donde será aplicado como solución.

27. Bibliografía
https://es.wikipedia.org/wiki/Diseño_orientado_a_objetos
http://arielvargasu.blogspot.com/2010/10/garantia-de-calidad-de-software-sqa_18.html
Autor: ArielVargas – Octubre 2010
https://es.wikipedia.org/wiki/Mantenimiento_de_software
http://www.pmoinformatica.com/2016/08/tecnicas-analisis-requerimientos.html
Autor: PmInformatica - Agosto 2016