Please enable JavaScript.
Coggle requires JavaScript to display documents.
Modelo de Diseño Construcción y pruebas de Software, image, image, image,…
Modelo de Diseño Construcción y pruebas de Software
Construcción de software
Actividades Principales de la Construcción de Software
Abordaje del Análisis del Modelado
Primeras pruebas
Crear constantemente
Evolución de la lógica de dominio
Evolucionar las interfaces de usuario
Evolucionar el esquema de datos
Desarrollo de interfaces de activos legados
Obtener la construcción completa del software.
Documentación Técnica completa.
Materiales para Soporte al Usuario completa.
Materiales para Capacitación.
Informe final de Verificación (conteniendo toda la información de la versión).
Evaluación de la calidad del producto
El término Software Construcción (Construcción del software) se refiere a la creación de software productivo y significativo a través de los procesos de codificación, verificación, pruebas unitarias, pruebas de integración y depuración de errores.
Diseño de la interfaz
• (1) el diseño de la interfaz entre los componentes del software;
• (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas)
• (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora
El diseño de la interfaz de usuario comienza con la identificación de los requerimientos del usuario, la tarea y el ambiente.
arquitectura de niveles o por capas
que el sistema cumpla con los requerimientos de los participantes del sistema.
desarrollo de la interfaz
A. Requiere de Métodos de Diseño Específicos
Constituye un Proceso Iterativo: El desarrollo de la interfaz conforma un proceso constante e iterativo de refinamientos sucesivos.
B. Prelación de la Etapa de Evaluación
Presenta una Etapa de Requerimientos incompleta: La etapa de requerimientos de la interfaz del usuario por lo general es ausente e incompleta.
C. Existe una Anticipación de las Etapas de Desarrollo
Presenta una Naturaleza Bottom-up: A diferencias del componente de aplicación, en donde el desarrollador tiene una visión global del problema y a partir de allí
D. Requiere de un Mecanismo de Representación Especial
Requiere de un Mecanismo de Representación Especial: La componente de interfaz necesita ser evaluada y probada por diferentes tipos de usuarios.
E. Presenta una Naturaleza Bottom-up
Requiere de Métodos de Diseño Específicos: La interfaz del usuario está conformada, por componentes tales como la de presentación, la componente de control de diálogo y la de modelo interfaz-aplicación.
F. Presenta una Etapa de Requerimientos incompleta
Existe una Anticipación de las Etapas de Desarrollo: es un proceso en donde se anticipan las etapas de desarrollo.
G. Constituye un Proceso Iterativo:
Prelación de la Etapa de Evaluación: La etapa de evaluación, en el caso del desarrollo de la componente de interfaz, es fundamental para probar la corrección y completitud de etapas previas, como las etapas de requerimientos o la de diseño.
H. Requiere Participación Activa de los Usuarios:
Requiere Participación Activa de los Usuarios: Por una cuestión que los factores humanos deben ser considerados en todo el proceso de desarrollo, el usuario debe participar en forma efectiva y sistemática
I. Es un Proceso Interdisciplinario
Es un Proceso Interdisciplinario: La creación de la interfaz del usuario
estándares
• ISO/IEC 10741 - 1: Interacción del Diálogo – Control de Cursores para edición de texto
• ISO/IEC 11581: Símbolos de Icono y Funciones
• ISO/IEC 18021: Tecnología de la Información – Interfaz de Usuario para herramientas móviles
• ISO/IEC TR 9126 - 2: Ingeniería del Software: Calidad del Producto
• ISO 9241: Requisitos ergonómicos para trabajo con terminales gráficas
• ISO 14915: Ergonomía del Software para interfaces de usuario multimedia
• IEC TR 61997: Guías para interfaces en equipos multimedia de propósito general
Tipos
1.Una interfaz de hardware, a nivel de los dispositivos utilizados para ingresar, procesar y entregar los datos: teclado, ratón y pantalla visualizadora.
2.Una interfaz de software, destinada a entregar información acerca de los procesos y herramientas de control, a través de lo que el usuario observa habitualmente en la pantalla.
3.Una interfaz de Software-Hardware, que establece un puente entre la máquina y las personas, permite a la máquina entender la instrucción y al hombre entender el código binario traducido a información legible.
4.Una La interfaz gráfica de usuario, conocida también como GUI (del inglés graphical user interface) es un programa informático que actúa de interfaz de usuario
Diseño
DISEÑO LÓGICO El diseño lógico parte del esquema conceptual que da como resultado un esquema lógico, que no es más que una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD,
DISEÑO FÍSICO El diseño físico parte del esquema lógico que da como resultado un esquema físico, el cual es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos.
DISEÑO CONCEPTUAL El diseño conceptual parte de las especificaciones de los requerimientos de usuario y su resultado es el esquema conceptual de la base de datos,
RUP
La fase de construcción se centra en el refinamiento de: Administración del Proyecto (plan para el proyecto o plan de desarrollo y la Lista de Riesgos). Requisitos Análisis y Diseño (Modelo de Diseño) Implementación (Modelo de la Implementación) Pruebas (Plan de Pruebas) Despliegue Objetivos: Minimizar costes con un uso eficaz de los recursos Obtener calidad tan rápidamente como sea práctico Obtener versiones útiles tan rápidamente como sea práctico. Resultados: El producto software Los manuales
objetivos
• El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.
• Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de la operaciones para optimizar costos, tiempo y calidad.
• Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación)
• Arquitectura íntegra (mantenida y mínimamente actualizada)
• Riesgos Presentados Mitigados
• Plan del Proyecto para la fase de Transición Manual Inicial de Usuario (con suficiente detalle)
• Prototipo Operacional – beta
• Caso del Negocio Actualizado
Actividades a realizar
• Análisis
• Puede no mantenerse
• Análisis de la arquitectura
• Analizar un caso de uso
• Analizar una clase
• Analizar un paquete
• Diseño
• Diseño de la arquitectura: prácticamente no se modifica
• Las otras tres tareas se realizan para el resto de los casos de uso
Plan de desarrollo
Los fundamentos de la construcción del software incluyen:
Minimizar la complejidad
Anticiparse a los cambios
Construir para verificar
Estándares en la construcción.
SWEBOK
Minimizar la complejidad
Anticiparse a los cambios
Construir para verificar
Estandares
Pruebas de software
flujo de trabajo
Planificar las Pruebas. El principal documento producido es el Plan de Pruebas.
Diseñar las Pruebas. Los principales artefactos producidos son el Modelo de Pruebas (Test Model), los Casos de Prueba (Test Case), los Procedimientos de Prueba (Test Procedures) y el documento de Análisis de Carga de Trabajo (Workload Analysis Document).
Implementar las Pruebas. Los principales artefactos producidos son el Script de la Prueba y el Componente de la Prueba.
Ejecutar las Pruebas en la etapa de Integración de Pruebas. El principal documento producido es el documento Resultado de Pruebas.
Ejecutar las Pruebas en la etapa de Pruebas del Sistema.El principal documento producido es el documento Resultado de Pruebas.
etapas
Pruebas de desarrollo, donde el sistema se pone a prueba durante el proceso para descubrir errores (bugs) y defectos. Es probable que en el desarrollo de prueba inter- vengan diseñadores y programadores del sistema.
Versiones de prueba, donde un equipo de prueba por separado experimenta una versión completa del sistema, antes de presentarlo a los usuarios. La meta de la prueba de versión es comprobar que el sistema cumpla con los requerimientos de los participantes del sistema.
Pruebas de usuario, donde los usuarios reales o potenciales de un sistema prueban el sistema en su propio entorno. Para productos de software, el “usuario” puede ser un grupo interno de marketing, que decide si el software se comercializa, se lanza y se vende. Las pruebas de aceptación se efectúan cuando el cliente prueba de manera formal un sistema para decidir si debe aceptarse del proveedor del sistema, o si se requiere más desarrollo
