Juan velasquez

Profesora:
Ing. Amelia Vásquez
SISTEMAS II
Autor:
Juan Carlos Velásquez D.
C.I:V - 9.821.694
Sección “SS”

INTRODUCCIÓNINTRODUCCIÓN
¡¡Bienvenidos…!
En el desarrollo de esta presentación, hablaremos sobre; Fundamento del diseño de Software, Fundamento del diseño. Diseño
orientado a objeto, Garantías de calidad del Software, Técnicas de pruebas de software, Mantenimiento de software
(preventivo, seguridad), Fundamentos al requerimiento del diseño: especificaciones, principios, Métodos de análisis de
requerimientos. El punto de partida principal para abordar el diseño es el documento de especificación de requisitos (SRD).
En la realización del diseño podemos destacar algunas características: Es un proceso creativo que no es nada trivial. Casi
siempre se lleva a cabo de una forma iterativa mediante prueba y error. Es muy importante la experiencia previa. El método
más eficaz es participar en algún diseño y aprender de otros diseñadores sus técnicas de trabajo. El diseño de Software juega
un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir
varios modelos del sistema o producto de que se va a construir el mismo que forman una especie de plan de la solución de la
aplicación. 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.

FUNDAMENTO DEL DISEÑO DE SOFTWAREFUNDAMENTO DEL DISEÑO DE SOFTWARE
Conceptos Generales de Diseño:
El software no es el único campo donde el diseño se encuentra inmiscuido. En general podemos ver el diseño como una forma
para resolución de problemas. El problema sin solución definitiva es interesante en términos de comprensión del diseño. Un
numero de otras nociones y conceptos son también de interés en la comprensión del diseño en su sentido general, objetivos,
limitaciones, alternativas, representaciones y soluciones
Contexto del Diseño de Software:
El diseño del software se encuentra en el núcleo técnico de la respectiva ingeniería y se aplica de manera independiente
al modelo de software que se utilice. Una vez que se analizan y especifican los requisitos, el diseño del software es la
última acción de la ingeniería correspondiente dentro de la actividad del modelado, la cual establece una plataforma para
la construcción (generación de código y prueba).
"El milagro más común de la ingeniería de software es la transición del análisis al diseño y del diseño al código“.
Richard Due
Proceso del Diseño de Software:
Diseño Arquitectónico.
El diseño arquitectónico puede representarse al usar uno o más de muchos modelos diferentes. Los modelos estructurales
representan la arquitectura como una colección organizada de componentes del programa. Los modelos del marco
de trabajo repetible incrementan el grado de abstracción del diseño al intentar identificar marcos de trabajo repetibles del
diseño arquitectónico que se encuentran en tipos de aplicaciones similares.
El diseño de la arquitectura de software se describe cómo se descompone y como están organizados los componentes en el
software. [IEEEP1471-00]
Diseño Detallado.
El diseño detallado se describe el comportamiento específico de estos componentes.
Técnicas Permitidas:
Abstracción:
Abstracción es el proceso o el resultado de la generalización de la reducción del contenido de la información de un concepto o
un fenómeno observable, por lo general, con el fin de conservar únicamente la información que es relevante para un propósito
en particular. Cuando se considera una solución modular a cualquier problema se pueden exponer muchos grados de
abstracción.

En un alto grado de abstracción una solución se establece en términos generales con el lenguaje del entorno del problema.
En los grados de menor abstracción se proporciona una descripción más detallada de la solución.
En la medida en que se cambian los diferentes grados de abstracción se trabaja para crear abstracciones procedimentales y
de datos
Abstracción Procedimental: Se refiere a una secuencia de instrucciones que tiene una función específica y limitada.
Abstracción de Datos: Es una colección nombrada de datos que describe un objeto de datos.
Acoplamiento y Cohesión.
Dentro del modelo de diseño es necesario que las clases de diseño colaboren con alguna otra.
Es una medida de la interconexión entre los módulos de la estructura de un programa. Depende de la complejidad de la interfaz
entre los módulos, el punto en el que se entra o se hace referencia al módulo y qué datos pasan a través de la interfaz. Intentamos
conseguir el menor nivel posible de acoplamiento. Las conexiones sencillas entre los módulos hacen que el software sea más
Fácil de entender y menos dado al efecto ola.
Acoplamiento: La fuerza de las relaciones entre los módulos.
Acoplamiento de datos: está subordinado al módulo y se accede a él por medio de una lista convencional de argumentos a
través de la cual se pasan los datos.
Acoplamiento de marca: cuando en vez de argumentos simples se pasa una porción de la estructura de datos se pasa por la
Interfaz del módulo.
Acoplamiento de control: se pasa un indicador de control (una variable que controla las decisiones en el módulo subordinado).

Una clase de diseño cohesiva tiene un conjunto de responsabilidades pequeño y enfocado, y aplica atributos y métodos de
manersencilla de implementar dichas responsabilidades.
Cohesión: Como están relacionados los elementos que conforman un modulo.
Es una extensión natural del concepto de ocultamiento de la información. Un módulo con cohesión realiza una sola tarea dentro
de un procedimiento de software, requiriendo poca interacción con los procedimientos que se realizan en otras partes del
programa. Un módulo con cohesión debería hacer una sola cosa.
Siempre debemos buscar la cohesión más alta, aunque la parte media del espectro es a menudo aceptable.
Coincidencialmente cohesivo: un módulo que realiza un conjunto de tareas poco relacionadas las unas con las otras.
Cohesión lógica: realiza tareas relacionadas lógicamente (produce todas las salidas).
Cohesión temporal: contienen tareas relacionadas por el hecho de que todas deben hacerse en el mismo intervalo de tiempo.
Cohesión procedimental: cuando los elementos de procesamiento están relacionados y deben ejecutarse en un orden
Específico.
Cohesión de comunicación: todos los elementos de procesamiento se concentran en un área de la estructura de datos.
La descomposición y la modularización.
Los patrones de arquitectura y diseño de software materializan la modularidad; es decir, el software se divide en componentes
con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados módulos se integran
para satisfacer los requisitos del problema.
Modularidad: Es el atributo particular del software que permite que un programa sea manejable de manera intelectual.
Se divide el software en componentes identificables y tratables por separado, denominados módulos, que están integrados para
satisfacer los requisitos del programa.

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).
Todos los lenguajes y plataformas actuales se basan en el paradigma de la programación orientada a objetos (OOP por sus siglas en
inglés). Aunque a diario trabajamos con objetos, no todo el mundo comprende realmente lo que es el polimorfismo o para qué
sirve una clase abstracta, por poner un ejemplo.
La potencia de la orientación a objetos lleva implícita mucha complejidad y una larga curva de aprendizaje. Lo que en unos casos
es una buena manera de resolver un problema, en otros es la forma de hacer el código más frágil. Es decir, no siempre conviene
crear una jerarquía de clases, dependiendo del caso puede ser más conveniente crear una asociación entre objetos que colaboran.
Desafortunadamente no hay reglas universales que sirvan para toda la gama de problemas que nos podamos encontrar pero hay
ciertos principios y patrones que nos pueden dar pistas sobre cual es el diseño más conveniente en un momento dado. Con fines
docentes se suele explicar la OOP mediante ejemplos relacionados con el mundo que conocemos: véase el típico ejemplo de la
clase Animal, de la que hereda la clase Mamífero, de la que a su vez hereda la claseCuadrúpedo, de la que a su vez heredan las
clases Perro y Gato
FUNDAMENTO DEL DISEÑO.FUNDAMENTO DEL DISEÑO.
DISEÑO ORIENTADO A OBJETODISEÑO ORIENTADO A OBJETO

Garantia de Calidad de Software (SQA):
Garantía de calidad del software (SQA) consiste en los medios de la supervisión tecnología de dotación lógica los procesos y los
métodos aseguraban calidad. Hace esto por medio de intervenciones de sistema de gerencia de la calidad debajo de cuál se crea el
sistema de software. Estas intervenciones son movidas hacia atrás por unos o más estándares, generalmenteISO 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.
“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las
necesidades o expectativas del cliente o usuario”.
La SQA (Software Quality Assurance) engloba:
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:
El control de la calidad es una serie de revisiones, y pruebasutilizados a los largo del ciclo de desarrollo para asegurar que cada
producto cumple con los requisitos que le han sido asignados.
La garantía de calidad o aseguramiento de la calidad consiste en la auditoria y las funciones de información de la gestión. El
objetivo de la garantía de la 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.
GARANTÍAS DE CALIDAD DEL SOFTWAREGARANTÍAS DE CALIDAD DEL SOFTWARE

Ventajas de la SQA:
Un plan de la SQA puede tomar un número de trayectorias, probando para diversas capacidades y la ejecución diferente analiza,
dependiendo de las demandas del proyecto, los usuarios, y el software.
Satisfacción de cliente mejorada: La satisfacción de cliente mejorada significa relaciones más de largo, más provechosas del
cliente.
Coste reducido de desarrollo: Porque el proceso de la garantía de calidad del software se diseña para prevenir defectos e ineficacias
del software, los proyectos que incorporan riguroso, prueba del objetivo encontrarán que los costes del desarrollo están reducidos
puesto que todas las fases más posteriores del ciclo vital del desarrollo llegan a ser aerodinámicas y simplificados
perceptiblemente.
Metodología de la SQA:
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 de la validación: La prueba de la validació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 Comparando 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.
Prueba de la tensión: Una prueba de tensió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 A veces 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
acabo mejoras a un interfaz.
Niveles de Maduración
Nivel 1. Inicial. En este nivel, los proyectos y métodos de ingeniería no se encuentran definidos. Por esta razón, los proyectos
son adelantados de manera incoherente, incontrolada y poco profesional. El éxito es eventual. Según la entidad certificadora
del CMM, el Instituto de Ingeniería de Software de los Estados Unidos (SEI), la mayoría de los grupos de desarrollo de
software en el mundo operan a este nivel.
Nivel 2. Repetible. Se establecen algunos procesos y métodos de ingeniería a nivel de proyectos.
Nivel 3. Definido. Los procesos, actividades y métodos relacionados con la ingeniería y administración de proyectos se
encuentran documentados, estandarizados y construidos alrededor de un marco integrado para toda la compañía.
Nivel 4. Administrado. La compañía opera bajo control estadístico de procesos. Los resultados de los procesos y la calidad de
los productos son predecibles.
Nivel 5. Optimización. En este nivel, las organizaciones se encuentran en un proceso de mejora continua. Las organizaciones
se enfocan en su mejora a través de técnicas de prevención de defectos, cambios en tecnología y en procesos. Según el SEI,
menos del 0,1% de las organizaciones del mundo se encuentran en nivel de madurez.

TÉCNICAS DE PRUEBAS DE SOFTWARE
Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar
información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el
proceso de control de calidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo desoftware. Dependiendo del tipo de pruebas, estas
actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de
desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las
actividades de desarrollo.

MANTENIMIENTO DE SOFTWARE
(PREVENTIVO, SEGURIDAD).
El mantenimiento preventivo de software es el proceso por el cual se mejora y optimiza el software que se ha instalado, este
mantenimiento se realiza para la prevención de posibles problemas que puedan llegar a surgir a medida que se utiliza el
computador.
La principal razón por la que se realiza este mantenimiento, en estos días es el análisis en busca de virus, ya que estos; los “Virus”
son programas nocivos para el computador, ya que causan una inestabilidad en el sistema, bajas en el rendimiento del computador,
perdida de productividad, cortes en los sistemas y probables errores en el mismo, tales que no se pueden corregir de manera
simple, sino mediante de una formateada. Para realizar un mantenimiento óptimo al software existen pasos para realizar este
eficientemente y tener una mayor cobertura en el mantenimiento. Estos pasos son:
•La revisión de instalación por SETUP.
•Desfragmentación de disco duro.
•La eliminación de archivos TMP.
•Liberación de espacio en el disco duro.
•Ejecución del antivirus.
•Realizar una copia de seguridad.
•Limpiar la papelera de reciclaje
La seguridad de software aplica los principios de la seguridad de información al desarrollo de software. Information
security (La seguridad de información) se refiere a la seguridad de información comúnmente
como la protección de sistemas de información contra el acceso desautorizado o la modificación de información, si está en
una fase de almacenamiento, procesamiento o tránsito.

MANTENIMIENTO DE SOFTWARE
(PREVENTIVO, SEGURIDAD).
.
También la protege contra la
negación de servicios a usuarios desautorizados y la provisión de servicio a usuarios desautorizados, incluyendo las
medidas necesarias para detectar, documentar, y contrariar tales amenazas.
Muchas preguntas con respecto a la seguridad, son relacionadas al ciclo vital de software. En particular, la seguridad del
código y el proceso de software; deben de ser considerados durante la fase del diseño y desarrollo.
Además, la seguridad debe de ser preservada durante la operación y el mantenimiento para asegurar la integridad de
una parte (pedazo) de software.
Una gran cantidad de seguridad usada en los Sistemas de Redes de hoy, nos pueden engañar en la
creencia que nuestros trabajos como diseñadores de sistema de seguridad ya han sido realizados. Sin embargo, las
cadenas y computadoras son increíblemente inseguras. La falta de seguridad se origina en
dos problemas fundamentales: Los sistemas que son teóricamente seguros pueden ser inseguros en la
práctica, Además los sistemas son cada vez más complejos. La complejidad proporciona más oportunidades para los
ataques. Es mucho más fácil probar que un sistema es inseguro que demostrar que
no es seguro probar la inseguridad, simplemente una toma ventaja de ciertas vulnerabilidades del sistema.

FUNDAMENTOS AL REQUERIMIENTO DEL
DISEÑO: ESPECIFICACIONES, PRINCIPIOS.
. La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en
detalle los requisitos del sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son
denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y
comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve
problemas y como negociador.
El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El
contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy
probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la
famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta
de que lo que escuchó no es lo que yo quise decir”.
El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema
y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características
operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y
establece las restricciones que debe cumplir el software.

MÉTODOS DE ANÁLISIS DEMÉTODOS DE ANÁLISIS DE
REQUERIMIENTOSREQUERIMIENTOS
La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan enLa ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en
detalle los requisitos del sistema y el papel asignado al software.detalle los requisitos del sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que sonTanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son
denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones ydenominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y
comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelvecomportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve
problemas y como negociador.problemas y como negociador.
El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. ElEl análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El
contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muycontenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy
probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo laprobable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la
famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se défamosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé
cuenta de que lo que escuchó no es lo que yo quise decir”.cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema yEl análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y
el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las característicasel diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características
operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema yoperacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y
establece las restricciones que debe cumplir el software.establece las restricciones que debe cumplir el software.

CONCLUSIÓNCONCLUSIÓN
DeDe Podemos concluir que el desarrollo de software es uno de los pilares fundamentales de la Informática y al cual se dedicanPodemos concluir que el desarrollo de software es uno de los pilares fundamentales de la Informática y al cual se dedican
muchas horas de esfuerzos en universidades, centros de investigación y empresas de todos los tamaños.muchas horas de esfuerzos en universidades, centros de investigación y empresas de todos los tamaños.
En el desarrollo de productos de software las etapas de análisis de requerimientos y diseño toma gran parte del tiempo delEn el desarrollo de productos de software las etapas de análisis de requerimientos y diseño toma gran parte del tiempo del
proyecto. El modelo planteado en este proyecto pretende establecer unos parámetros de diseño generales que permitan agilizarproyecto. El modelo planteado en este proyecto pretende establecer unos parámetros de diseño generales que permitan agilizar
la implementación de proyectos tipo sistemas de control por software, cuya base común es el procesamiento de señalesla implementación de proyectos tipo sistemas de control por software, cuya base común es el procesamiento de señales
digitales en busca de comportamientos de interés caracterización de señalesdigitales en busca de comportamientos de interés caracterización de señales
Conforme la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas formas de programación, nuevos lenguajes,Conforme la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas formas de programación, nuevos lenguajes,
y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco mas fácil. También surgen nuevosy un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco mas fácil. También surgen nuevos
modelos de proceso de desarrollo y nuevas metodologías que tratan de adaptar la manera de trabajar a las necesidadesmodelos de proceso de desarrollo y nuevas metodologías que tratan de adaptar la manera de trabajar a las necesidades
concretas de una organización y de sus proyectosconcretas de una organización y de sus proyectos

WEBGRAFIAWEBGRAFIA
• https://sistemas-de-informacion.wikispaces.com/Fases+de+Sistema+de+Informaci%C3%B3nhttps://sistemas-de-informacion.wikispaces.com/Fases+de+Sistema+de+Informaci%C3%B3n
• https://www.google.co.ve/search?q=CICLO+DE+VIDA+DE+SISTEMAS+DE+INFORMACIhttps://www.google.co.ve/search?q=CICLO+DE+VIDA+DE+SISTEMAS+DE+INFORMACI
%C3%93N&rlz=1C1CHBD_esVE762VE762&oq=CICLO+DE+VIDA+DE+SISTEMAS+DE+INFORMACI%C3%93N&rlz=1C1CHBD_esVE762VE762&oq=CICLO+DE+VIDA+DE+SISTEMAS+DE+INFORMACI
%C3%93N&aqs=chrome..69i57j0l5.1105j0j8&sourceid=chrome&ie=UTF-8%C3%93N&aqs=chrome..69i57j0l5.1105j0j8&sourceid=chrome&ie=UTF-8
• http://ejemplosde.org/informatica/sistema-de-informacion/#ixzz5BuxG55ojhttp://ejemplosde.org/informatica/sistema-de-informacion/#ixzz5BuxG55oj
• http://www.monografias.com/trabajos94/analisis-y-diseno-sistemas-informacion/analisis-y-diseno-sistemas-http://www.monografias.com/trabajos94/analisis-y-diseno-sistemas-informacion/analisis-y-diseno-sistemas-
informacion.shtmlinformacion.shtml
• http://www.oocities.org/siliconvalley/pines/7894/sistemas/diseno.htmlhttp://www.oocities.org/siliconvalley/pines/7894/sistemas/diseno.html

Juan velasquez

Más contenido relacionado

La actualidad más candente

Similar a Juan velasquez

Más de Juan Carlos Velasquez Duerto

Último

Juan velasquez