SlideShare a Scribd company logo
1 of 33
Wendy Oliveros CI: 21676071
Nicola Pizzi CI: 20140117
Fundamentos
de Diseño
 A través de la historia de la ingeniería del software ha
evolucionado un conjunto de conceptos fundamentales
de diseño de software, aunque el grado deinterés en
cada concepto ha variado con los años, han pasado la
prueba del tiempo ofreciendo cada uno al ingeniero de
software fundamentos sobre el cual pueden
aplicarse métodos de diseño más elaborados.
 El diseño de Software juega un papel importante en
el desarrollo de software lo cual permite al ingeniero de
software producir
varios modelos delsistema o producto de que se va a
construir el mismo que forman una especie de plan de
la solución de la aplicación.
DISEÑO DE SOFTWARE
DISEÑO DE SOFTWARE
 Estos modelos puede evaluarse en relación con
su calidad y mejorarse antes de generar código, de
realizar pruebas y de que los usuarios finales se vean
involucrados a gran escala. El diseño es el sitio en el
que se establece la calidad del software.
 El diseño del software se encuentra en el núcleo técnico
de la ingeniería del software y se aplica
independientemente del modelo de diseño de software
que se utilice.
 Una vez que se analizan y especifican los requisitos del
software, el diseño del software es la primera de las tres
actividades técnicas - diseño, generación de código y
pruebas- que se requieren para construir y verificar el
software.
IMPORTANCIA DEL DISEÑO DE SOFTWARE
 La importancia del diseño del software se puede
describir con una sola palabra -calidad-. El diseño es el
lugar en donde se fomentará la calidad en la ingeniería
del software. El diseño proporciona las
representaciones del software que se pueden evaluar
en cuanto a calidad. El diseño es la única forma de
convertir exactamente los requisitos de un cliente en un
producto o sistema de software finalizado. El dise- ño
del software sirve como fundamento para todos los
pasos siguientes del soporte del software y de la
ingeniería del software.
PERSISTENCIAS, ALMACENAMIENTO,
EXCEPCIONES ENTRE OTRAS
 Persistencia es el "arte" de almacenar
y/o recuperar el estado de un objeto. No
todo campo de un objeto requiere
persistir, puede ser calculado, en tal
caso a ese campo se lo llama
trasciente. Por ejemplo si tengo una
clase que representa un triángulo
rectángulo entonces el estado a
almacenarse corresponderá a las
dimensión de los lados, mientras que la
hipotenusa es un campo trasciente ya
que resulta de aplicar la eterna
ecuación pitagórica.
PERSISTENCIAS, ALMACENAMIENTO,
EXCEPCIONES ENTRE OTRAS
 Los almacenes de datos internos y externos dentro de
un sistema proporcionan puntos limpios de separación
entre subsistemas con interfaces bien definidas. En
general, todo almacén de datos puede
combinar estructuras de datos, archivos y bases de
datos implementados en memoria o bien en dispositivos
de almacenamiento secundario. Los distintos tipos de
almacenes de datos proporcionan diversas
compensaciones entre costo, tiempo de acceso,
capacidad y fiabilidad.
MÉTODOS PARA LA ACTIVIDAD DE DISEÑO
 Resulta necesario establecer un enfoque sistemático y
disciplinado para llevar a cabo un desarrollo software.
 Una metodología de ingeniería del software es un
proceso para producir software de forma organizada,
empleando una colección de técnicas y convenciones
de notación predefinidas.
 Conjunto de procedimientos, técnicas, herramientas y
un soporte documental que ayuda a los desarrolladores
a realizar nuevo software.
MÉTODOS PARA LA ACTIVIDAD DE DISEÑO
 Un conjunto estructurado de actividades y resultados
asociados que conducen a la creación de un producto
de software:
 Especificación de requisitos: Definir la funcionalidad y
las restricciones en sus operaciones
 Diseño e implementación: Producir software que cumple
la especificación
 Validación: Asegurar que hace lo que el cliente desea.
 Mantenimiento (o Evolución): Seguir cumpliendo los
cambios en las necesidades del usuario.
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
Un buen diseñador
debería considerar
enfoques alternativos
Se debería poder
seguir los pasos del
diseño hasta el modelo
del análisis
El diseñador no debe
inventar nada de lo
que ya esté inventado
Uniformidad e
integración
Debe estructurarse
para admitir cambios
Estructurarse para
degradarse poco a
poco
El diseño no es escribir
códigos y viceversa
Valorar el diseño
mientras se crea
Revisar el diseño para
minimizar errores
conceptuales
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
 El diseño de interacción determina las posibilidades de
operación de un sistema tecnológico: las posibilidades
de acción de las personas que lo usarán, y las
reacciones del sistema ante estas acciones.
 El diseño de interacción y el diseño de la interfaz son
mutuamente dependientes, muchas veces las
decisiones de un plano condicionarán las decisiones en
el otro plano.
 Hasta el momento1, los sistemas electrónicos y
tecnológicos en general, no están dotados de
inteligencia propia. Todo sistema será tan inteligente
como su diseño permita.
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
 El diseño de interacción comienza durante las etapas
estratégicas del diseño, con la definición de
requerimientos y funcionalidades, elementos claves que
dan forma a la estrategia del sistema. Al hablar de
diseño estratégico nos referimos a decisiones de
negocios que permiten elegir una estrategia a tomar con
un producto: estrategias de diferenciación de la
competencia, audiencia primaria a enfocar el producto.
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
 El diseño de un producto tecnológico es un proceso
complejo con múltiples dimensiones, estas decisiones
estratégicas dan forma al producto, aunque muchas
veces se las considere fuera del proceso de diseño.
 Para crear un diseño amigable es fundamental entender
a las personas que usarán el sistema, por esto parte
importante de este trabajo consiste en entrevistar
personas que representen al tipo de usuario final del
sistema. Empaparse del modo de pensar, las
necesidades y el lenguaje de los usuarios permitirá al
diseñador estar en mejor pie para anticipar sus
expectativas y reacciones, generando una interacción
natural para ellos.
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
○ Los atributos de calidad son las cualidades o
propiedades de calidad que la aplicación debe
satisfacer.
o La calidad de una aplicación se mide en función de
sus atributos de calidad.
o Para facilitar su medición durante la verificación,
deben expresarse cuantitativa o cualitativamente.
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
Del Software
Asociado a la Funcionalidad
Asociado a la Confiabilidad
Asociado a la Utilidad
Asociado a la Eficiencia
Calidad
Asociado a la Mantenibilidad
Asociado a la Portabilidad
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 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.
 Una arquitectura de software se selecciona y diseña
con base en objetivos y restricciones. Los objetivos son
aquellos prefijados para el sistema de información, pero
no solamente los de tipo funcional, también otros
objetivos como la mantenibilidad, auditabilidad,
flexibilidad e interacción con otros sistemas de
información.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Las restricciones son aquellas limitaciones derivadas de
las tecnologías disponibles para implementar sistemas
de información. Unas arquitecturas son más
recomendables de implementar con ciertas tecnologías
mientras que otras tecnologías no son aptas para
determinadas arquitecturas. Por ejemplo, no es viable
emplear una arquitectura de software de tres capas
para implementar sistemas en tiempo real.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 En toda tarea humana, podemos encontrar una serie
de patrones que se repiten. Incluso en las bellas artes,
actividad representativa de la creatividad humana,
podemos hallar características comunes que nos
permiten clasificar las obras en distintos movimientos
artísticos. Y cómo no, en el arte de la programación no
iba a ser menos.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Era de esperar, por tanto, que alguien se animara tarde
o temprano a estudiar los distintos patrones que pueden
encontrarse en la inmensa mayoría del software, de
forma que los problemas solucionados por estos
quedasen perfectamente clasificados junto con su
solución, para que así no fuese necesario reinventar la
rueda cada vez que un programador se enfrentase a un
obstáculo similar al descrito en uno de estos patrones.
Nacieron así los patrones de diseño de sistemas
software.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Un patrón de diseño debe cumplir al menos dos
requisitos para considerarse como tal: Debe ser
efectivo, de modo que se haya podido comprobar su
éxito resolviendo problemas anteriores; y debe
ser reutilizable, es decir, podemos aplicarlo a problemas
que se hallan en circunstancias similares a las descritas
por el patrón.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Imagina cuán sencillo sería poder comentar un
problema de diseño con un compañero, y poder decirle
algo tan sencillo como: “Esto es un patrón adapter”;
siendo este breve comentario suficiente como para que
tu interlocutor te entendiese perfectamente y sepa cómo
hay que resolver el problema al que te enfrentas.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 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.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Si solamente tienes un proyecto, aún así deberías
reutilizar. Deberías separar código reutilizable en
una librería lo que te permitirá simplificar aún más el
código a mantener.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 DISEÑO ORIENTADO A FUNCIONES
(ESTRUCTURADO)
 El diseño estructurado se utiliza generalmente
después de un análisis estructurado, cuyo
producto es el diagrama de flujo de datos y las
descripciones de procesos. Los investigadores
han propuesto diversas estrategias y heurísticas,
como por ejemplo fan-in/fan-out, para
transformar un DFD en una arquitectura de
software en general representada como una
estructura chart.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Como un método de diseño, ésta es realmente una
combinación de dos técnicas diferentes,
interrelacionadas. La primera es el Análisis de Sistemas
Estructurados(SSA), que se ocupa de la construcción
de un modelo del problema mediante el uso de
Diagramas de Flujo de Datos (DFD). La segunda es el
diseño estructurado (SD), que a su vez se orienta hacia
los aspectos relacionados con la búsqueda de
soluciones (diseño detallado) mediante el uso de la
estructura chart.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 DISEÑO ORIENTADO A OBJETOS
 Existen numerosos métodos de diseño
de software basado en objetos que han
sido propuestos desde la década de
1980. De manera informal, de acuerdo a
su elaboración, se los ubica en tres
generaciones (Budgen, 2003):
 •Métodos de primera generación:
Desarrollados en la década de 1970 y
principios de 1980, estos métodos
tienen una tendencia evolutiva. Se
caracterizan por tener formas limitadas
de notación diagramática y procesos
débiles.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Este método no ofrece una forma eficaz para el uso de
la propiedad de herencia y el concepto de jerarquía de
clases. Sin embargo, se limita exclusivamente a las
características de objetos como: la modularidad, el
encapsulamiento y la abstracción.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 •Métodos de segunda generación: Desarrollados a
mediados de la década de 1990, estos métodos son
considerados revolucionarios. El método Fusión
desarrollado en 1994 integra y amplia los elementos de
mayor éxito de las prácticas existentes hasta ese
entonces. Al igual que HOOD, Fusión emplea una
combinación de texto y diagramas, aunque la
proporción de diagramas es mucho mayor. Fusión
cuenta con un diagrama de clase (Denominado el
modelo de objetos) que trata de proporcionar un punto
de vista de la construcción de un sistema. Mientras que
el modelado del comportamiento de clase hace uso de
descripciones textuales.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 El Proceso Unificado: Surgió en la década de 1990
como resultado de unir las ideas y enfoques empleados
por Booch, Jacobson y Rumbaugh. Se relaciona
estrechamente con el desarrollo en paralelo de UML.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 DISEÑO BASADO EN COMPONENTES
 Un componente de software es una unidad
independiente, que posee interfaces bien definidas y
dependencias que pueden ser construidas e
implementadas de forma separada. El diseño basado
en componentes busca proveer, desarrollar e integrar
dichos componentes (Budgen, 2003).
 Una de las principales razones para optar por este
diseño es promover la reutilización, la misma que
permite reducir los costos de elaboración del producto
final (Budgen, 2003). Existen dos características que se
deben tomar en cuenta para la reutilización:
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Funcionalidad bien definida, para facilitar la
identificación de los componentes útiles, que satisfagan
los requerimientos.
 Los componentes deben tener interfaces bien definidas
que permitan su interrelación.
 Sin embargo, existen varios problemas relacionados al
diseño utilizando componentes:
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Búsqueda del Componente: es una tarea complicada
encontrar un componente que satisfaga la funcionalidad
indicada para un sistema. Es necesario identificar
claramente las necesidades generales del problema,
para luego buscar un conjunto de componentes que
colectivamente resuelvan estas necesidades.
 Integración de componentes: pueden darse casos en
los cuales el conjunto de componentes no logra
satisfacer la funcionalidad requerida. De igual forma,
existe la posibilidad de que dos o más componentes
brinden la misma funcionalidad. Incluso, existe la
posibilidad de una incompatibilidad arquitectónica entre
componentes.

More Related Content

What's hot

MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMicky Jerzy
 
Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4Enrique Barreiro
 
Arquitectura de Sistemas de Bases de datos
Arquitectura de Sistemas de Bases de datosArquitectura de Sistemas de Bases de datos
Arquitectura de Sistemas de Bases de datosnegriz
 
Prototipos
PrototiposPrototipos
PrototiposTensor
 
Desarrollo basado en patrones
Desarrollo basado en patronesDesarrollo basado en patrones
Desarrollo basado en patronesMarvin Zumbado
 
Ingeniería de software es la aplicación de un enfoque sistemático
Ingeniería de software es la aplicación de un enfoque sistemáticoIngeniería de software es la aplicación de un enfoque sistemático
Ingeniería de software es la aplicación de un enfoque sistemáticoSantiago Moha
 
Software Quality Assurance
Software Quality AssuranceSoftware Quality Assurance
Software Quality AssuranceSiddhesh Palkar
 
Calidad de software - usabilidad y accesibilidad
Calidad de software - usabilidad y accesibilidadCalidad de software - usabilidad y accesibilidad
Calidad de software - usabilidad y accesibilidadRodrigo Ronda
 
Análisis de arquitecturas de software
Análisis de arquitecturas de softwareAnálisis de arquitecturas de software
Análisis de arquitecturas de softwareJorge Rodriguez
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoSergio Sanchez
 
51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-software51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-softwareMiguel Angel Rodriguez
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosCesar Prado
 
INF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWARE
INF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWAREINF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWARE
INF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWAREFely Villalba
 
Factores de calidad según mc call
Factores de calidad según mc callFactores de calidad según mc call
Factores de calidad según mc callclauddiaa
 
Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6koolkampus
 

What's hot (20)

Ensayo ingenieria de requisitos
Ensayo ingenieria de requisitosEnsayo ingenieria de requisitos
Ensayo ingenieria de requisitos
 
MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWARE
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4
 
Arquitectura de Sistemas de Bases de datos
Arquitectura de Sistemas de Bases de datosArquitectura de Sistemas de Bases de datos
Arquitectura de Sistemas de Bases de datos
 
Prototipos
PrototiposPrototipos
Prototipos
 
Desarrollo basado en patrones
Desarrollo basado en patronesDesarrollo basado en patrones
Desarrollo basado en patrones
 
Ingeniería de software es la aplicación de un enfoque sistemático
Ingeniería de software es la aplicación de un enfoque sistemáticoIngeniería de software es la aplicación de un enfoque sistemático
Ingeniería de software es la aplicación de un enfoque sistemático
 
Software Quality Assurance
Software Quality AssuranceSoftware Quality Assurance
Software Quality Assurance
 
Calidad de software - usabilidad y accesibilidad
Calidad de software - usabilidad y accesibilidadCalidad de software - usabilidad y accesibilidad
Calidad de software - usabilidad y accesibilidad
 
Análisis de arquitecturas de software
Análisis de arquitecturas de softwareAnálisis de arquitecturas de software
Análisis de arquitecturas de software
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De Uso
 
3. Análisis de Requerimientos
3. Análisis de Requerimientos3. Análisis de Requerimientos
3. Análisis de Requerimientos
 
51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-software51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-software
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Rup (iteraciones)
Rup (iteraciones)Rup (iteraciones)
Rup (iteraciones)
 
Chap3 RE elicitation
Chap3 RE elicitationChap3 RE elicitation
Chap3 RE elicitation
 
INF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWARE
INF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWAREINF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWARE
INF-162 GRUPO 6 MODELOS DE PROCESO DE SOFTWARE
 
Factores de calidad según mc call
Factores de calidad según mc callFactores de calidad según mc call
Factores de calidad según mc call
 
Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6
 

Viewers also liked

Aspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xdAspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xdDiego Estacio
 
14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de software14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de softwareJhon Barrera
 
Fundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño IIFundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño IIGerardo González
 
Fundamentos de la ingenieria del software
Fundamentos de la ingenieria del softwareFundamentos de la ingenieria del software
Fundamentos de la ingenieria del softwarealberto calatayu
 
Principios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwarePrincipios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwareJose Patricio Bovet Derpich
 
METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREMETODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREadark
 
Unidad 1 - Fundamentos del diseño gráfico
Unidad 1  - Fundamentos del diseño gráficoUnidad 1  - Fundamentos del diseño gráfico
Unidad 1 - Fundamentos del diseño gráficoFidel Romero
 
Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de softwareIker Canarias
 

Viewers also liked (13)

Aspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xdAspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xd
 
14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de software14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de software
 
Fundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño IIFundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño II
 
Fundamentos de la ingenieria del software
Fundamentos de la ingenieria del softwareFundamentos de la ingenieria del software
Fundamentos de la ingenieria del software
 
Principios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwarePrincipios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del software
 
Top down
Top downTop down
Top down
 
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
 
METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREMETODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
 
Diseño de Software
Diseño de SoftwareDiseño de Software
Diseño de Software
 
Unidad 1 - Fundamentos del diseño gráfico
Unidad 1  - Fundamentos del diseño gráficoUnidad 1  - Fundamentos del diseño gráfico
Unidad 1 - Fundamentos del diseño gráfico
 
Fundamentos del diseño
Fundamentos del diseñoFundamentos del diseño
Fundamentos del diseño
 
Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de software
 

Similar to Fundamentos de Diseño - Grupo Delta

Actividad remedial_Maria_Albarran
Actividad remedial_Maria_AlbarranActividad remedial_Maria_Albarran
Actividad remedial_Maria_AlbarranMarijoalbarranb
 
Unidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareUnidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareJahiro Bojorquez
 
Metodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemasMetodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemasgrupo7inf162
 
1. ciclo de_vida_de_software
1. ciclo de_vida_de_software1. ciclo de_vida_de_software
1. ciclo de_vida_de_softwareMiguel Castro
 
Fundamentos de diseño de software
Fundamentos de diseño de softwareFundamentos de diseño de software
Fundamentos de diseño de softwareLuis Jesus Curbata
 
Presentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro LucesPresentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro LucesPedroLuces3
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de softwareLiliana Pacheco
 
Ingeniería de software
Ingeniería de software Ingeniería de software
Ingeniería de software jevo1994
 
Tecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwareTecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwarejuankexmisiodj
 
Ingeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetosIngeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetosWilfredo Mogollón
 
Tarea semana 1
Tarea semana 1Tarea semana 1
Tarea semana 1preciadoag
 
Fundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareFundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareJesús Molleda
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemasgrupo7inf162
 

Similar to Fundamentos de Diseño - Grupo Delta (20)

Actividad remedial_Maria_Albarran
Actividad remedial_Maria_AlbarranActividad remedial_Maria_Albarran
Actividad remedial_Maria_Albarran
 
Unidad v
Unidad vUnidad v
Unidad v
 
Unidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareUnidad 1 Ingenieria de software
Unidad 1 Ingenieria de software
 
Metodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemasMetodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemas
 
1. ciclo de_vida_de_software
1. ciclo de_vida_de_software1. ciclo de_vida_de_software
1. ciclo de_vida_de_software
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Fundamentos de diseño de software
Fundamentos de diseño de softwareFundamentos de diseño de software
Fundamentos de diseño de software
 
Omar,luis,daniel
Omar,luis,danielOmar,luis,daniel
Omar,luis,daniel
 
Presentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro LucesPresentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro Luces
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 
Ingeniería de software
Ingeniería de software Ingeniería de software
Ingeniería de software
 
Tecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwareTecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.software
 
Adrian adrianza
Adrian adrianzaAdrian adrianza
Adrian adrianza
 
Ingeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetosIngeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetos
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
8.conceptos de diseño
8.conceptos de diseño8.conceptos de diseño
8.conceptos de diseño
 
Tarea semana 1
Tarea semana 1Tarea semana 1
Tarea semana 1
 
Tareasemana1
Tareasemana1Tareasemana1
Tareasemana1
 
Fundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareFundamentos basicos del diseño de software
Fundamentos basicos del diseño de software
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemas
 

Recently uploaded

Infografía EE con pie del 2023 (3)-1.pdf
Infografía EE con pie del 2023 (3)-1.pdfInfografía EE con pie del 2023 (3)-1.pdf
Infografía EE con pie del 2023 (3)-1.pdfAlfaresbilingual
 
Tema 19. Inmunología y el sistema inmunitario 2024
Tema 19. Inmunología y el sistema inmunitario 2024Tema 19. Inmunología y el sistema inmunitario 2024
Tema 19. Inmunología y el sistema inmunitario 2024IES Vicent Andres Estelles
 
origen y desarrollo del ensayo literario
origen y desarrollo del ensayo literarioorigen y desarrollo del ensayo literario
origen y desarrollo del ensayo literarioELIASAURELIOCHAVEZCA1
 
6°_GRADO_-_MAYO_06 para sexto grado de primaria
6°_GRADO_-_MAYO_06 para sexto grado de primaria6°_GRADO_-_MAYO_06 para sexto grado de primaria
6°_GRADO_-_MAYO_06 para sexto grado de primariaWilian24
 
SESION DE PERSONAL SOCIAL. La convivencia en familia 22-04-24 -.doc
SESION DE PERSONAL SOCIAL.  La convivencia en familia 22-04-24  -.docSESION DE PERSONAL SOCIAL.  La convivencia en familia 22-04-24  -.doc
SESION DE PERSONAL SOCIAL. La convivencia en familia 22-04-24 -.docRodneyFrankCUADROSMI
 
RESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptx
RESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptxRESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptx
RESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptxpvtablets2023
 
Concepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptxConcepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptxFernando Solis
 
INSTRUCCION PREPARATORIA DE TIRO .pptx
INSTRUCCION PREPARATORIA DE TIRO   .pptxINSTRUCCION PREPARATORIA DE TIRO   .pptx
INSTRUCCION PREPARATORIA DE TIRO .pptxdeimerhdz21
 
Procedimientos para la planificación en los Centros Educativos tipo V ( multi...
Procedimientos para la planificación en los Centros Educativos tipo V ( multi...Procedimientos para la planificación en los Centros Educativos tipo V ( multi...
Procedimientos para la planificación en los Centros Educativos tipo V ( multi...Katherine Concepcion Gonzalez
 
PINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).ppt
PINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).pptPINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).ppt
PINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).pptAlberto Rubio
 
La Sostenibilidad Corporativa. Administración Ambiental
La Sostenibilidad Corporativa. Administración AmbientalLa Sostenibilidad Corporativa. Administración Ambiental
La Sostenibilidad Corporativa. Administración AmbientalJonathanCovena1
 
2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptx
2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptx2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptx
2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptxRigoTito
 
Los avatares para el juego dramático en entornos virtuales
Los avatares para el juego dramático en entornos virtualesLos avatares para el juego dramático en entornos virtuales
Los avatares para el juego dramático en entornos virtualesMarisolMartinez707897
 
Tema 17. Biología de los microorganismos 2024
Tema 17. Biología de los microorganismos 2024Tema 17. Biología de los microorganismos 2024
Tema 17. Biología de los microorganismos 2024IES Vicent Andres Estelles
 
Prueba libre de Geografía para obtención título Bachillerato - 2024
Prueba libre de Geografía para obtención título Bachillerato - 2024Prueba libre de Geografía para obtención título Bachillerato - 2024
Prueba libre de Geografía para obtención título Bachillerato - 2024Juan Martín Martín
 
ACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLA
ACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLAACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLA
ACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLAJAVIER SOLIS NOYOLA
 

Recently uploaded (20)

Interpretación de cortes geológicos 2024
Interpretación de cortes geológicos 2024Interpretación de cortes geológicos 2024
Interpretación de cortes geológicos 2024
 
Infografía EE con pie del 2023 (3)-1.pdf
Infografía EE con pie del 2023 (3)-1.pdfInfografía EE con pie del 2023 (3)-1.pdf
Infografía EE con pie del 2023 (3)-1.pdf
 
Tema 19. Inmunología y el sistema inmunitario 2024
Tema 19. Inmunología y el sistema inmunitario 2024Tema 19. Inmunología y el sistema inmunitario 2024
Tema 19. Inmunología y el sistema inmunitario 2024
 
Lecciones 06 Esc. Sabática. Los dos testigos
Lecciones 06 Esc. Sabática. Los dos testigosLecciones 06 Esc. Sabática. Los dos testigos
Lecciones 06 Esc. Sabática. Los dos testigos
 
origen y desarrollo del ensayo literario
origen y desarrollo del ensayo literarioorigen y desarrollo del ensayo literario
origen y desarrollo del ensayo literario
 
Tema 11. Dinámica de la hidrosfera 2024
Tema 11.  Dinámica de la hidrosfera 2024Tema 11.  Dinámica de la hidrosfera 2024
Tema 11. Dinámica de la hidrosfera 2024
 
6°_GRADO_-_MAYO_06 para sexto grado de primaria
6°_GRADO_-_MAYO_06 para sexto grado de primaria6°_GRADO_-_MAYO_06 para sexto grado de primaria
6°_GRADO_-_MAYO_06 para sexto grado de primaria
 
SESION DE PERSONAL SOCIAL. La convivencia en familia 22-04-24 -.doc
SESION DE PERSONAL SOCIAL.  La convivencia en familia 22-04-24  -.docSESION DE PERSONAL SOCIAL.  La convivencia en familia 22-04-24  -.doc
SESION DE PERSONAL SOCIAL. La convivencia en familia 22-04-24 -.doc
 
RESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptx
RESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptxRESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptx
RESULTADOS DE LA EVALUACIÓN DIAGNÓSTICA 2024 - ACTUALIZADA.pptx
 
Concepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptxConcepto y definición de tipos de Datos Abstractos en c++.pptx
Concepto y definición de tipos de Datos Abstractos en c++.pptx
 
INSTRUCCION PREPARATORIA DE TIRO .pptx
INSTRUCCION PREPARATORIA DE TIRO   .pptxINSTRUCCION PREPARATORIA DE TIRO   .pptx
INSTRUCCION PREPARATORIA DE TIRO .pptx
 
Procedimientos para la planificación en los Centros Educativos tipo V ( multi...
Procedimientos para la planificación en los Centros Educativos tipo V ( multi...Procedimientos para la planificación en los Centros Educativos tipo V ( multi...
Procedimientos para la planificación en los Centros Educativos tipo V ( multi...
 
PINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).ppt
PINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).pptPINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).ppt
PINTURA DEL RENACIMIENTO EN ESPAÑA (SIGLO XVI).ppt
 
La Sostenibilidad Corporativa. Administración Ambiental
La Sostenibilidad Corporativa. Administración AmbientalLa Sostenibilidad Corporativa. Administración Ambiental
La Sostenibilidad Corporativa. Administración Ambiental
 
2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptx
2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptx2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptx
2 REGLAMENTO RM 0912-2024 DE MODALIDADES DE GRADUACIÓN_.pptx
 
Sesión de clase APC: Los dos testigos.pdf
Sesión de clase APC: Los dos testigos.pdfSesión de clase APC: Los dos testigos.pdf
Sesión de clase APC: Los dos testigos.pdf
 
Los avatares para el juego dramático en entornos virtuales
Los avatares para el juego dramático en entornos virtualesLos avatares para el juego dramático en entornos virtuales
Los avatares para el juego dramático en entornos virtuales
 
Tema 17. Biología de los microorganismos 2024
Tema 17. Biología de los microorganismos 2024Tema 17. Biología de los microorganismos 2024
Tema 17. Biología de los microorganismos 2024
 
Prueba libre de Geografía para obtención título Bachillerato - 2024
Prueba libre de Geografía para obtención título Bachillerato - 2024Prueba libre de Geografía para obtención título Bachillerato - 2024
Prueba libre de Geografía para obtención título Bachillerato - 2024
 
ACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLA
ACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLAACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLA
ACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLA
 

Fundamentos de Diseño - Grupo Delta

  • 1. Wendy Oliveros CI: 21676071 Nicola Pizzi CI: 20140117 Fundamentos de Diseño
  • 2.  A través de la historia de la ingeniería del software ha evolucionado un conjunto de conceptos fundamentales de diseño de software, aunque el grado deinterés en cada concepto ha variado con los años, han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software fundamentos sobre el cual pueden aplicarse métodos de diseño más elaborados.  El diseño de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir varios modelos delsistema o producto de que se va a construir el mismo que forman una especie de plan de la solución de la aplicación. DISEÑO DE SOFTWARE
  • 3. DISEÑO DE SOFTWARE  Estos modelos puede evaluarse en relación con su calidad y mejorarse antes de generar código, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El diseño es el sitio en el que se establece la calidad del software.  El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice.  Una vez que se analizan y especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas - diseño, generación de código y pruebas- que se requieren para construir y verificar el software.
  • 4. IMPORTANCIA DEL DISEÑO DE SOFTWARE  La importancia del diseño del software se puede describir con una sola palabra -calidad-. El diseño es el lugar en donde se fomentará la calidad en la ingeniería del software. El diseño proporciona las representaciones del software que se pueden evaluar en cuanto a calidad. El diseño es la única forma de convertir exactamente los requisitos de un cliente en un producto o sistema de software finalizado. El dise- ño del software sirve como fundamento para todos los pasos siguientes del soporte del software y de la ingeniería del software.
  • 5. PERSISTENCIAS, ALMACENAMIENTO, EXCEPCIONES ENTRE OTRAS  Persistencia es el "arte" de almacenar y/o recuperar el estado de un objeto. No todo campo de un objeto requiere persistir, puede ser calculado, en tal caso a ese campo se lo llama trasciente. Por ejemplo si tengo una clase que representa un triángulo rectángulo entonces el estado a almacenarse corresponderá a las dimensión de los lados, mientras que la hipotenusa es un campo trasciente ya que resulta de aplicar la eterna ecuación pitagórica.
  • 6. PERSISTENCIAS, ALMACENAMIENTO, EXCEPCIONES ENTRE OTRAS  Los almacenes de datos internos y externos dentro de un sistema proporcionan puntos limpios de separación entre subsistemas con interfaces bien definidas. En general, todo almacén de datos puede combinar estructuras de datos, archivos y bases de datos implementados en memoria o bien en dispositivos de almacenamiento secundario. Los distintos tipos de almacenes de datos proporcionan diversas compensaciones entre costo, tiempo de acceso, capacidad y fiabilidad.
  • 7. MÉTODOS PARA LA ACTIVIDAD DE DISEÑO  Resulta necesario establecer un enfoque sistemático y disciplinado para llevar a cabo un desarrollo software.  Una metodología de ingeniería del software es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas.  Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.
  • 8. MÉTODOS PARA LA ACTIVIDAD DE DISEÑO  Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software:  Especificación de requisitos: Definir la funcionalidad y las restricciones en sus operaciones  Diseño e implementación: Producir software que cumple la especificación  Validación: Asegurar que hace lo que el cliente desea.  Mantenimiento (o Evolución): Seguir cumpliendo los cambios en las necesidades del usuario.
  • 9. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS Un buen diseñador debería considerar enfoques alternativos Se debería poder seguir los pasos del diseño hasta el modelo del análisis El diseñador no debe inventar nada de lo que ya esté inventado Uniformidad e integración Debe estructurarse para admitir cambios Estructurarse para degradarse poco a poco El diseño no es escribir códigos y viceversa Valorar el diseño mientras se crea Revisar el diseño para minimizar errores conceptuales
  • 10. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS  El diseño de interacción determina las posibilidades de operación de un sistema tecnológico: las posibilidades de acción de las personas que lo usarán, y las reacciones del sistema ante estas acciones.  El diseño de interacción y el diseño de la interfaz son mutuamente dependientes, muchas veces las decisiones de un plano condicionarán las decisiones en el otro plano.  Hasta el momento1, los sistemas electrónicos y tecnológicos en general, no están dotados de inteligencia propia. Todo sistema será tan inteligente como su diseño permita.
  • 11. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS  El diseño de interacción comienza durante las etapas estratégicas del diseño, con la definición de requerimientos y funcionalidades, elementos claves que dan forma a la estrategia del sistema. Al hablar de diseño estratégico nos referimos a decisiones de negocios que permiten elegir una estrategia a tomar con un producto: estrategias de diferenciación de la competencia, audiencia primaria a enfocar el producto.
  • 12. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS  El diseño de un producto tecnológico es un proceso complejo con múltiples dimensiones, estas decisiones estratégicas dan forma al producto, aunque muchas veces se las considere fuera del proceso de diseño.  Para crear un diseño amigable es fundamental entender a las personas que usarán el sistema, por esto parte importante de este trabajo consiste en entrevistar personas que representen al tipo de usuario final del sistema. Empaparse del modo de pensar, las necesidades y el lenguaje de los usuarios permitirá al diseñador estar en mejor pie para anticipar sus expectativas y reacciones, generando una interacción natural para ellos.
  • 13. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD) ○ Los atributos de calidad son las cualidades o propiedades de calidad que la aplicación debe satisfacer. o La calidad de una aplicación se mide en función de sus atributos de calidad. o Para facilitar su medición durante la verificación, deben expresarse cuantitativa o cualitativamente.
  • 14. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD) Del Software Asociado a la Funcionalidad Asociado a la Confiabilidad Asociado a la Utilidad Asociado a la Eficiencia Calidad Asociado a la Mantenibilidad Asociado a la Portabilidad
  • 15. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
  • 16. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
  • 17. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  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.  Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información.
  • 18. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
  • 19. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  En toda tarea humana, podemos encontrar una serie de patrones que se repiten. Incluso en las bellas artes, actividad representativa de la creatividad humana, podemos hallar características comunes que nos permiten clasificar las obras en distintos movimientos artísticos. Y cómo no, en el arte de la programación no iba a ser menos.
  • 20. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Era de esperar, por tanto, que alguien se animara tarde o temprano a estudiar los distintos patrones que pueden encontrarse en la inmensa mayoría del software, de forma que los problemas solucionados por estos quedasen perfectamente clasificados junto con su solución, para que así no fuese necesario reinventar la rueda cada vez que un programador se enfrentase a un obstáculo similar al descrito en uno de estos patrones. Nacieron así los patrones de diseño de sistemas software.
  • 21. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Un patrón de diseño debe cumplir al menos dos requisitos para considerarse como tal: Debe ser efectivo, de modo que se haya podido comprobar su éxito resolviendo problemas anteriores; y debe ser reutilizable, es decir, podemos aplicarlo a problemas que se hallan en circunstancias similares a las descritas por el patrón.
  • 22. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Imagina cuán sencillo sería poder comentar un problema de diseño con un compañero, y poder decirle algo tan sencillo como: “Esto es un patrón adapter”; siendo este breve comentario suficiente como para que tu interlocutor te entendiese perfectamente y sepa cómo hay que resolver el problema al que te enfrentas.
  • 23. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  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.
  • 24. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Si solamente tienes un proyecto, aún así deberías reutilizar. Deberías separar código reutilizable en una librería lo que te permitirá simplificar aún más el código a mantener.
  • 25. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  DISEÑO ORIENTADO A FUNCIONES (ESTRUCTURADO)  El diseño estructurado se utiliza generalmente después de un análisis estructurado, cuyo producto es el diagrama de flujo de datos y las descripciones de procesos. Los investigadores han propuesto diversas estrategias y heurísticas, como por ejemplo fan-in/fan-out, para transformar un DFD en una arquitectura de software en general representada como una estructura chart.
  • 26. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Como un método de diseño, ésta es realmente una combinación de dos técnicas diferentes, interrelacionadas. La primera es el Análisis de Sistemas Estructurados(SSA), que se ocupa de la construcción de un modelo del problema mediante el uso de Diagramas de Flujo de Datos (DFD). La segunda es el diseño estructurado (SD), que a su vez se orienta hacia los aspectos relacionados con la búsqueda de soluciones (diseño detallado) mediante el uso de la estructura chart.
  • 27. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  DISEÑO ORIENTADO A OBJETOS  Existen numerosos métodos de diseño de software basado en objetos que han sido propuestos desde la década de 1980. De manera informal, de acuerdo a su elaboración, se los ubica en tres generaciones (Budgen, 2003):  •Métodos de primera generación: Desarrollados en la década de 1970 y principios de 1980, estos métodos tienen una tendencia evolutiva. Se caracterizan por tener formas limitadas de notación diagramática y procesos débiles.
  • 28. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Este método no ofrece una forma eficaz para el uso de la propiedad de herencia y el concepto de jerarquía de clases. Sin embargo, se limita exclusivamente a las características de objetos como: la modularidad, el encapsulamiento y la abstracción.
  • 29. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  •Métodos de segunda generación: Desarrollados a mediados de la década de 1990, estos métodos son considerados revolucionarios. El método Fusión desarrollado en 1994 integra y amplia los elementos de mayor éxito de las prácticas existentes hasta ese entonces. Al igual que HOOD, Fusión emplea una combinación de texto y diagramas, aunque la proporción de diagramas es mucho mayor. Fusión cuenta con un diagrama de clase (Denominado el modelo de objetos) que trata de proporcionar un punto de vista de la construcción de un sistema. Mientras que el modelado del comportamiento de clase hace uso de descripciones textuales.
  • 30. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  El Proceso Unificado: Surgió en la década de 1990 como resultado de unir las ideas y enfoques empleados por Booch, Jacobson y Rumbaugh. Se relaciona estrechamente con el desarrollo en paralelo de UML.
  • 31. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  DISEÑO BASADO EN COMPONENTES  Un componente de software es una unidad independiente, que posee interfaces bien definidas y dependencias que pueden ser construidas e implementadas de forma separada. El diseño basado en componentes busca proveer, desarrollar e integrar dichos componentes (Budgen, 2003).  Una de las principales razones para optar por este diseño es promover la reutilización, la misma que permite reducir los costos de elaboración del producto final (Budgen, 2003). Existen dos características que se deben tomar en cuenta para la reutilización:
  • 32. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Funcionalidad bien definida, para facilitar la identificación de los componentes útiles, que satisfagan los requerimientos.  Los componentes deben tener interfaces bien definidas que permitan su interrelación.  Sin embargo, existen varios problemas relacionados al diseño utilizando componentes:
  • 33. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Búsqueda del Componente: es una tarea complicada encontrar un componente que satisfaga la funcionalidad indicada para un sistema. Es necesario identificar claramente las necesidades generales del problema, para luego buscar un conjunto de componentes que colectivamente resuelvan estas necesidades.  Integración de componentes: pueden darse casos en los cuales el conjunto de componentes no logra satisfacer la funcionalidad requerida. De igual forma, existe la posibilidad de que dos o más componentes brinden la misma funcionalidad. Incluso, existe la posibilidad de una incompatibilidad arquitectónica entre componentes.