2. Introduccion
2
El diseño es importante porque permite que un equipo de software evalúe la
calidad de éste antes de que se implemente, momento en el que es fácil y
barato corregir errores, omisiones o inconsistencias.
Durante el diseño, la calidad se evalúa por medio de la realización de una
serie de revisiones técnicas. Una revisión técnica es una reunión celebrada
por miembros del equipo de software. Por lo general, participan dos, tres o
cuatro personas, en función del alcance de la información del diseño que se
revisará.
3. El diseño de software
⋆ Es un proceso iterativo por medio del cual se traducen los
requerimientos en un “plano” para construir el software. Al
principio, el plano ilustra una visión holística del software.
Es decir, el diseño se representa en un nivel alto de abstracción, en
el que se rastrea directamente el objetivo específico del sistema y los
requerimientos más detallados de datos, funcionamiento y
comportamiento. A medida que tienen lugar las iteraciones del diseño,
las mejoras posteriores conducen a niveles menores de abstracción
⋆
3
4. Lineamientos para el diseño
⋆ Debe tener una arquitectura que a) se haya creado
con el empleo de estilos o patrones
arquitectónicos reconocibles, b) esté compuesta
de componentes con buenas características de
diseño y c) se implementen en forma evolutiva de
modo que faciliten la implementación y las
pruebas.
⋆ Debe ser modular, es decir, el software debe estar
dividido de manera lógica en elementos o
subsistemas.
⋆ Debe contener distintas representaciones de
datos, arquitectura, interfaces y componentes.
⋆ Debe conducir a estructuras de datos apropiadas
para las clases que se van a implementar y que
surjan de patrones reconocibles de datos.
⋆ Debe llevar a componentes que tengan
características funcionales independientes.
⋆ Debe conducir a interfaces que reduzcan la
complejidad de las conexiones entre los
componentes y el ambiente externo.
⋆ Debe obtenerse con el empleo de un método
repetible motivado por la información obtenida
durante el análisis de los requerimientos del
software.
⋆ Debe representarse con una notación que
comunique con eficacia su significado
4
5. 1.
Fundamentos del diseño
orientado a objetos
El diseño Orientado a Objetos (DOO) difiere considerablemente del
diseño estructurado ya que en DOO no se realiza un problema en
términos de tareas (subrutinas) ni en términos de datos, sino que
se analiza el problema como un sistema de objetos que interactúan
entre sí.
6. Un problema desarrollado con técnicas orientadas a objetos requiere, en
primer lugar saber cuáles son los objetos del programa. Como tales
objetos son instancias de clases, la primera etapa en el desarrollo
orientado a objetos requiere de la identificación de dichas clases
(atributos y comportamiento), así como las relaciones entre éstas y
su posterior implementación en un lenguaje de programación.
Aunque no siempre están bien delimitadas las etapas de análisis y diseño
en la OO, se pueden sintetizar de alguna forma las ideas claves de las
distintas tecnologías existentes dentro del desarrollo orientado a
objetos al que denominaremos diseño.
En el diseño orientado a objetos, los objetos necesitan interactuar y
comunicarse, para realizar dicha comunicación, los objetos utilizan su
propia interfaz pública, dicha interfaz se compone principalmente de
métodos y propiedades.
El diseño orientado a objetos transforma el modelo del análisis en un
modelo de diseño que sirve como anteproyecto para la construcción
de software.
7. características
Los objetos son abstracciones del mundo real o entidades del sistema que
se administran entre ellas mismas.
Los objetos son independientes y encapsulan el estado y la representación
de información.
La funcionalidad del sistema se expresa en términos de servicios de los
objetos.
Las áreas de datos compartidas son eliminadas. Los objetos se comunican
mediante paso de parámetros.
Los objetos pueden estar distribuidos y pueden ejecutarse en forma
secuencial o en paralelo
VENTAJAS
•Fácil de mantener, los objetos representan entidades
auto-contenidas
•Los objetos son componentes reutilizables
•Para algunos sistemas, puede haber un mapeo obvio
entre las entidades del mundo real y los objetos del
sistema
8. Componentes del Diseño
Orientado a Objetos
⋆ La identificación de objetos, sus atributos y
servicios
⋆ La organización de objetos dentro de una jerarquía
⋆ La construcción de descripciones dinámicas de
objetos que muestran como se usan los
⋆ servicios
⋆ La especificación de interfaces de objetos
. 8
9. Garantia 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
9
Engloba:
• 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.
10. 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.
PROPÓSITO DE SQA
Proporcionar visibilidad sobre procesos utilizados por el proyecto de SW y sobre los
productos que genera.
10
Ventajas
•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.
11. Pruebas del software
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
a cabo mejoras a un
interfaz.
11
12. REQUERIMIENTOS DE
DISEÑO DE SOFTWARE
Debemos tener claros todos los
requerimientos que afectan al Diseño del
Software.
Estos pueden ser funcionales o no, pero
deberán estar completamente definidos,
entendidos y documentados. Casi todos los
problemas futuros comienzan por no tener
claros los requisitos. Estos deberán 100%
claros y sin ambigüedades.
12
13. En la ingeniería de software, un
Análisis de Requerimientos es una
tarea que cubre el hueco entre la
definición del software a nivel
sistema y el diseño del mismo. Tanto el
desarrollador como el cliente tienen
un papel activo, pues juntos
definen en detalle los requisitos del
sistema a desarrollar y los pasos a
seguir. 13
14. 14
Conclusiones
⋆ En el desarrollo de productos de software las etapas de
análisis de requerimientos y diseño toma gran parte del
tiempo del proyecto
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