Etapa 1 Conceptualización - Proyecto de software

Descrição

Mapa Mental sobre Etapa 1 Conceptualización - Proyecto de software, criado por María García em 09-02-2022.
María García
Mapa Mental por María García, atualizado more than 1 year ago
María García
Criado por María García mais de 2 anos atrás
392
0

Resumo de Recurso

Etapa 1 Conceptualización - Proyecto de software
  1. Modelo de requisitos: tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecerá desde la perspectiva del usuario.
    1. El diagrama de la figura 6.1 ilustra los distintos modelos, los detalles y la notación
        1. ► Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.
          1. ► Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, lo que lo hace un modelo lógico independiente del ambiente de implementación.
            1. ► Diseño: La funcionalidad de los casos de uso, ya estructurada por el análisis, la realiza el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.
              1. ► Implementación: Los casos de uso se instrumentan mediante el código fuente en el modelo de implementación.
                1. ► Pruebas: Los casos de uso se comprueban a través de las pruebas de componentes y de integración.
                  1. ► Documentación: El modelo de casos de uso se debe registrar a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, de administración, etcétera.
                2. En la metodología de Objectory, el modelo de requisitos consta de tres modelos principales, visualmente representado por un diagrama de tres dimensiones como se muestra en la figura 6.2.
                    1. ► El modelo de comportamiento, basado directamente del modelo de casos de uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario.
                      1. ► El modelo de presentación o modelo de interfaces (o borde) especifica cómo interactúa el sistema con actores externos al ejecutar los casos de uso.
                        1. ► El modelo de información o modelo del dominio del problema especifica los aspectos estructurales de la aplicación en términos de objetos.
                    2. MODELO DE DISEÑO. Se considera como una formalización del espacio de análisis, extendiéndolo para incluir una dimensión adicional que corresponde al ambiente de implementación, como se ve en el diagrama de la figura 8.1.
                        1. Como el modelo de análisis define la arquitectura general del sistema, se busca obtener una arquitectura detallada como resultado del modelo de diseño, de manera que haya una continuidad de refinamiento entre los dos modelos
                        2. MODELO DE ANALISIS. Cuando ya se ha desarrollado y aceptado el modelo de requisitos, se inicia el desarrollo del modelo de análisis siguiendo el modelo de casos de uno,1 cuyo objetivo es comprender y generar una arquitectura de objetos para el sistema con base en lo especificado en el modelo de requisitos. Durante esta etapa no se considera el ambiente de implementación, modelando el sistema bajo condiciones ideales.
                          1. Figura 7.1 El diagrama muestra conceptualmente el modelo de análisis junto con la arquitectura general de objetos, en relación con el modelo de requisitos anteriormente desarrollado.
                          2. Durante el modelo de implementación se adapta al lenguaje de programación y/o la base de datos, según la especificación del diseño y las propiedades del lenguaje de implementación y base de datos. Aunque el diseño de objetos es bastante independeniente del lenguaje actual, todos los lenguajes tienen sus particularidades, las cuales deben adecuarse durante la implementación final
                            1. MODELO DE PRUEBA. Debe ser planificado con anticipación y de manera integral junto con el desarrollo del sistema. Es un error pensar que las pruebas son la última actividad del desarrollo, ya que no se puede lograr software de alta calidad sólo mediante pruebas finales y depuraciones. Las mismas deben hacerse simultáneamente con el desarrollo del sistema. Además, las pruebas finales deben tener como objetivo la certificación final de la calidad del producto y no la búsqueda de errores

                              Semelhante

                              Biologia e Geologia - Geologia 10º ano, parte I - Ensino Secundário Português
                              Heres Oliveira
                              Plano de Estudo - Semana 1
                              Alessandra S.
                              TROVADORISMO
                              Denise Teófilo
                              Progressão Aritmética (P.A.)
                              claudiac_
                              Engenharia de Produção
                              ismael-airoso
                              Genética Molecular: Ácidos Nucleicos
                              Renata Cavazzana
                              Artigo Científico - estrutura
                              alineadc
                              BIOLOGIA
                              neusamiotto
                              Mitos e Verdades: Salário X Motivação
                              Liliane Tubino
                              SIMULADÃO EA-HSG FATOS DA HISTÓRIA NAVAL PARTE 2
                              isac rodrigues
                              Crise da República e a ruptura de 1930
                              jacson luft