Ingeniería del Software de Gestión. Tema 3

71 %
29 %
Information about Ingeniería del Software de Gestión. Tema 3
Technology

Published on January 18, 2009

Author: kikebar

Source: slideshare.net

Description

Transparencias del Tema 3 (Análisis de Sistemas) de la asignatura Ingeniería del Software de Gestión de la Escuela Superior de Ingeniería Informática.

tema 3 – análisis de sistemas enrique barreiro departamento de informática universidade de vigo escuela superior de ingeniería informática ingeniería del software de gestión

introducción al análisis tema 3 – análisis de sistemas ingeniería de requisitos los casos de uso son una buena herramienta para capturar requisitos, pero siempre quedan aspectos sin resolver o que son de especial complejidad y hay que estudiar posteriormente: deben mantenerse lo más independientes posibles unos de otros, obviando detalles relativos a interacciones, concurrencia, recursos compartidos,... ejemplo: Ingresar Dinero y Retirar Dinero son dos casos de uso que acceden a la misma cuenta y por tanto están relacionados deben escribirse utilizando el lenguaje del cliente: al usarse lenguaje natural se pierde poder expresivo y en la captura de requisitos pueden quedar sin describir adecuadamente detalles que requieren notaciones más formales escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 92

introducción al análisis tema 3 – análisis de sistemas análisis objetivo: conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y ayude a estructurar todo el sistema, incluyendo su Ingeniería de arquitectura requerimientos diversos enfoques Modelo de casos estructurado de uso prototipado :Modelo orientado a objetos Análisis se analizan los requisitos descritos durante la ingeniería de requisitos: Modelo de análisis analizándolos con mayor profundidad: se :Modelo puede razonar más sobre los aspectos internos del sistema, resolviendo cuestiones sobre interacciones de casos de uso, recursos Diseño compartidos,... utilizando el lenguaje de los desarrolladores, lo que permite indicar detalles no Modelo de especificados antes (refinar los requisitos) diseño :Modelo se pueden estructurar los requisitos para facilitar su comprensión, preparación, modificación y mantenimiento escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 3 / 92

introducción al análisis tema 3 – análisis de sistemas Comparación del modelo de casos de uso con el modelo de análisis Modelo de casos de uso Modelo de análisis Descrito con el lenguaje del cliente Descrito con el lenguaje del desarrollador Vista externa del sistema Vista interna del sistema Estructurado por los casos de uso Estructurado por clases y paquetes Utilizado fundamentalmente como contrato entre Utilizado fundamentalmente por los el cliente y los desarrolladores sobre qué debería desarrolladores para comprender cómo debería y qué no debería hacer el sistema darse forma al sistema, es decir, cómo debería ser diseñado e implementado Puede contener redundancias, inconsistencias,... No debe contener redundancias, entre los requisitos inconsistencias,... entre los requisitos Captura la funcionalidad del sistema, incluida la Esboza cómo llevar a cabo la funcionalidad dentro funcionalidad significativa para la arquitectura del sistema, incluida la funcionalidad significativa para la arquitectura; sirve como una primera aproximación al diseño Define casos de uso que se analizarán con más Define realizaciones de casos de uso y cada una profundidad en el modelo de análisis de ellas representa el análisis de un caso de uso del modelo de casos de uso escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 4 / 92

introducción al análisis tema 3 – análisis de sistemas requerimientos cambiantes habitual en grandes sistemas razones muchos usuarios (contradicciones, conflictos de intereses,...) los que pagan el sistema y los usuarios no suelen ser la misma persona, por lo que pueden tener requerimientos en conflicto el entorno de negocios y técnico cambia: nuevo hardware, nuevos sistemas, cambios en las prioridades del negocio, cambios legislativos,... administración de requerimientos proceso de comprender y controlar los cambios en los requerimientos del sistema requerimientos duraderos: aquellos relativamente estables, derivados de la actividad principal de la organización, y relacionados directamente con el dominio del sistema. Por ejemplo, en un hospital siempre habrá requerimientos referidos a pacientes, doctores, enfermeros, medicinas,... requerimientos volátiles: cambian probablemente durante el desarrollo del sistema o después de que se haya puesto en explotación. Por ejemplo, cambios en las normativas de salud. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 5 / 92

introducción al análisis tema 3 – análisis de sistemas planificación de la administración de requerimientos identificación de requerimientos proceso de administración del cambio análisis del problema y especificación del cambio análisis del cambio y evaluación económica implementación del cambio políticas de rastreo: definen la relación entre requerimientos y la de éstos y el diseño del sistema información de rastreo de la fuente: identificación de quién propone el cambio y la razón información de rastreo de los requerimientos: vincula los requerimientos dependientes en el RAD. Es necesario para comprobar cómo se ven afectados otros requerimientos por el cambio propuesto y la magnitud de este impacto. información de rastreo del diseño: vincula los requerimientos a los componentes de diseño (clases, métodos, módulos,...) en que serán implementados. Necesario para evaluar cómo se ve afectado el diseño y la implementación por el cambio propuesto. ayuda de herramientas CASE escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 6 / 92

el análisis en el proceso unificado tema 3 – análisis de sistemas actividades del análisis en el proceso unificado crear el Modelo de Dominio refinar el Modelo de Casos de Uso refinar la Especificación Complementaria refinar el Glosario se llevan a cabo a lo largo de varias iteraciones en la fase de elaboración escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 7 / 92

modelo del dominio tema 3 – análisis de sistemas artefacto de UML: modelo del dominio (o modelo conceptual) muestra clases conceptuales significativas en un dominio del problema, es decir, en el mundo real no muestra componentes software, clases software u objetos software con responsabilidades es el artefacto más importante en un análisis orientado a objetos (AOO) UML utiliza diagramas de clases para representar el modelo del dominio, que muestran: objetos del dominio o clases conceptuales asociaciones entre las clases conceptuales atributos de las clases conceptuales principal tarea del AOO: identificar diferentes conceptos en el dominio del problema y documentar el resultado en un modelo del dominio ejemplo: en el dominio de ventas pueden identificarse clases conceptuales como Tienda, Registro o Venta. el modelo del dominio se construye incrementalmente a lo largo de varias iteraciones en la fase de elaboración escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 8 / 92

modelo del dominio tema 3 – análisis de sistemas Modelo del dominio: ejemplo de un Diagrama de Clases concepto u Registra-venta-de LineaDeVenta Artículo objeto del cantidad dominio 0..1 1 * 1..n asociación Contenida-en Almacenado-en 1 Tienda 1 atributos dirección Venta tienda fecha hora 1 1 1 Capturada-en Alberga 1 Pagada-mediante 1.. * Registro 1 Pago cantidad escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 9 / 92

modelo del dominio tema 3 – análisis de sistemas pasos en la realización de un modelo del dominio 1. identificar y listar las clases conceptuales candidatas 2. representarlas en un modelo del dominio 3. añadir las asociaciones necesarias para registrar las relaciones que hay que mantener en memoria 4. añadir los atributos necesarios para satisfacer los requisitos de información importante: utilizar el vocabulario del dominio al nombrar las clases conceptuales y atributos excluir las características irrelevantes no añadir cosas que no se encuentran en el dominio del problema que se está estudiando escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 10 / 92

modelo del dominio tema 3 – análisis de sistemas Los modelos del dominio no son modelos de Los modelos del dominio no son modelos de componentes software. componentes software. Elementos que no son adecuados en un modelo del Elementos que no son adecuados en un modelo del dominio: Venta dominio: • Artefactos software: ventanas, bases de datos,... fecha • Artefactos software: ventanas, bases de datos,... • Responsabilidades o métodos • Responsabilidades o métodos hora imprimir() BaseDeDatosVentas Son artefactos software o clases s oftware, por lo que no forman parte del m odelo del do m ini o Componente Acti veX escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 11 / 92

modelo del dominio tema 3 – análisis de sistemas clases conceptuales informalmente: una clase conceptual es una idea, cosa u objeto formalmente puede considerarse en términos de: símbolo: palabras o imágenes que representan una clase conceptual definición de la clase extensión: conjunto de ejemplos a los que se aplica la clase símbolo del concepto Venta fecha hora venta-3 venta-1 venta-4 definición del concepto venta-2 Una venta representa el hechoventa representa el Una de una transición de compra.una transición hecho de Sucede un día ycompra. Sucede un de a una hora. día y a una hora. extensión del concepto escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 12 / 92

modelo del dominio tema 3 – análisis de sistemas identificación de clases conceptuales para cada escenario se identifican las clases conceptuales relacionadas con él Identificar clases mejor especificar en exceso un modelo c oncept uales candidat as del dominio con muchas clases conceptuales “de grano fino” que especificar por defecto Representar las clases en estrategias complementarias para un modelo del dominio identificar clases conceptuales utilización de una lista de categorías de clases conceptuales identificación de frases nominales Añadir las asociac iones necesarias Añadir los atributos necesarios escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 13 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas identificación de clases conceptuales mediante una lista de categorías se utiliza una lista de categorías habituales que normalmente merece la pena tener en cuenta Categoría de clase conceptual Ejemplos objetos tangibles o físicos Registro Avión especificaciones, diseños o descripciones EspecificacionDelProducto de las cosas DescripcionDelVuelo lugares Tienda transacciones Venta, Pago Reserva líneas de la transacción LineaDeVenta roles de la gente Cajero Piloto contenedores de otras cosas Tienda, Almacén Avión cosas en un contenedor Artículo Pasajero otros sistemas informáticos o SistemaAutorizaciónPagoCrédito electromecánicos externos al sistema ControlDeTraficoAereo ... ... escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 14 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas análisis del lenguaje natural: identificación de clases conceptuales mediante frases nominales heurística de Abbot (1983) identificar nombres y frases nominales en las descripciones textuales de un dominio, considerándolos como clases conceptuales o atributos candidatos punto débil: imprecisión del lenguaje natural, ambigüedades (sinónimos, redundancias,...) se realiza a partir de las descripciones completas de los casos de uso escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 15 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas Escenario principal de éxito (o flujo básico) de Procesar Venta. Escenario principal de éxito (o flujo básico) de Procesar Venta. 1. El Cliente llega al terminal PDV con mercancías y/o servicios que comprar 1. El Cliente llega al terminal PDV con mercancías y/o servicios que comprar 2. El Cajero inicia una nueva venta 2. El Cajero inicia una nueva venta 3. El Cajero introduce el identificador del artículo 3. El Cajero introduce el identificador del artículo 4. El Sistema registra la línea de venta y presenta la descripción del artículo, 4. El Sistema registra la línea de venta y presenta la descripción del artículo, precio y suma parcial. El precio se calcula a partir de un conjunto de reglas precio y suma parcial. El precio se calcula a partir de un conjunto de reglas de precios. de precios. El Cajero repite los pasos 3-4 hasta que se indique El Cajero repite los pasos 3-4 hasta que se indique 5. El Sistema muestra el total con los impuestos calculados 5. El Sistema muestra el total con los impuestos calculados 6. El Cajero le dice al Cliente el total, y solicita el pago 6. El Cajero le dice al Cliente el total, y solicita el pago 7. El Cliente paga y el Sistema gestiona el pago 7. El Cliente paga y el Sistema gestiona el pago 8. El Sistema registra la venta completa y envía la información de la venta y el 8. El Sistema registra la venta completa y envía la información de la venta y el pago al sistema de Contabilidad externo (para la contabilidad y las pago al sistema de Contabilidad externo (para la contabilidad y las comisiones) y al sistema de Inventario (para actualizar el inventario). comisiones) y al sistema de Inventario (para actualizar el inventario). 9. El sistema presenta el recibo 9. El sistema presenta el recibo 10. El Cliente se va con el recibo y las mercancías 10. El Cliente se va con el recibo y las mercancías Extensiones (o flujos alternativos) Extensiones (o flujos alternativos) ... ... 7a. Pago en efectivo: 7a. Pago en efectivo: 1. El Cajero introduce la cantidad de dinero entregada en efectivo. 1. El Cajero introduce la cantidad de dinero entregada en efectivo. 2. El sistema muestra la cantidad de dinero aa devolver y abre el cajón de 2. El sistema muestra la cantidad de dinero devolver y abre el cajón de caja. caja. 3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente 3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente 4. El Sistema registra el pago en efectivo 4. El Sistema registra el pago en efectivo escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 16 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas no se menciona de forma explícita, pero en la no se menciona de forma explícita, pero en la descripción se habla de “información enviada conocimiento descripción se habla de “información enviada conocimiento por el OficialCampo”. del dominio por el OficialCampo”. informar del dominio Al hablar con el cliente se descubre que a esta Al hablar con el cliente se descubre que a esta emergencia información se la conoce como informe de información se la conoce como informe de emergencia, por lo que se le da ese nombre a la emergencia, por lo que se le da ese nombre a la clase correspondiente clase correspondiente Ubicación Descripción del caso de uso Ubicación Descripción deldel caso de usouso Descripción Ubicación caso de Estación 1. El OficialCampo activa la función Informar Ubicación OficialCampo DescripciónOficialCampo activa la función Informar Emergencia en su PDA. uso El del caso de 1. Emergencia en su PDA. 1. El OficialCampo activa la función Informar 2. El sistema COMUNICA responde presentando un formulario alCOMUNICA responde presentando un su PDA. la función Informar 1. El OficialCampo activa 2. El sistema OficialCampo. El formulario incluye Emergencia en Estación un menú de al OficialCampo. El formulario incluye formulario tipos de emergencia (incendio, accidente, de tipos de emergencia para introducir en su PDA. Emergencia un menú disturbios,...) y campos (incendio, OficialCampo accidente, disturbios,...)del incidente, petición de y campos para introducir la ubicación, descripción El sistema COMUNICA responde presentando la 2. ubicación, descripción del incidente, petición de recursos,... 2. unEl sistema COMUNICA responde presentando formulario al OficialCampo. El formulario recursos,... un formulario al OficialCampo. El formulario 3. El OficialCampo cubre el formulario, y puede El OficialCampo cubre el formulario, a la menú de tipos de emergencia incluye un InformeDeEmergencia 3. también describir respuestas posibles y puede Controlador también describir respuestas posibles a la (incendio, un menú de tipos de emergencia incluye accidente, disturbios,...) y campos situación de emergencia y solicitar recursos específicos. Una vez que hasolicitar recursos situación de emergencia y llenado el formulario, elespecíficos. Una vez que ha(incendio, accidente, disturbios,...) y campos OficialCampo lo envía oprimiendo elel formulario, ubicación, descripción del para introducir la llenado botón “Enviar Informe” ylo envíaincidente,notifica al la ubicación, descripción del el OficialCampo en ese momento seel botón oprimiendo le para introducir “Enviar Informe” y en ese momento se le petición de recursos,... notifica al Controlador incidente, petición de recursos,... Controlador 4. Al Controlador se le notifica un nuevo informe de Estación incidente mediante le notifica un nuevo informe de cubre el formulario, y puede Al 3. Controlador se un cuadro OficialCampo El de diálogo 4. Controlador desplegable. El Controlador revisa diálogo incidente mediante un cuadro de la información 3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la recibida y crea El Controlador revisa la información desplegable. un Incidente en la base de datos llamando alcrea un Incidente también datos situaciónde describir respuestas posibles a la en la base de emergencia y solicitar recursos recibida y caso de uso AbrirIncidente. Toda la información contenidauso específicos.de emergencia y llenado el llamando al caso de en el formulario delToda la AbrirIncidente. información se incluye automáticamente en Una vez que ha solicitar recursos situación OficialCampocontenida en el formulario del el OficialCampo Incidente OficialCampo se incluye automáticamente en el Una vez que ha llenado el específicos. formulario, el OficialCampo lo envía oprimiendo Incidente. El Controlador selecciona una respuesta Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) yincidente (con el“Enviar OficialCampo lo envía oprimiendo el formulario, al Informe” y en ese momento se botón caso el asignando recursos al da un acuse de recibode uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando botónal Controlador informe de emergencia le el notifica “Enviar Informe” y en ese momento se un mensaje breve al OficialCampo. enviando un mensaje le notifica al Controlador breve al OficialCampo. Estación 5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada. el acuse de recibo y la se le notifica un nuevo informe El 4. OficialCampo recibe Al Controlador 5. OficialCampo respuesta seleccionada. 4. deAl Controlador se le notifica un de diálogo incidente mediante un cuadro nuevo informe Estación desplegable. Elmediante un cuadro la diálogo de incidente Controlador revisa de Controlador desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos recibida y al caso de uso información llamando crea un Incidente en la descripción de los objetos y clases AbrirIncidente. Toda la informaciónde uso base de datos llamando al caso contenida enAbrirIncidente. Toda la informaciónincluye el formulario del OficialCampo se contenida automáticamente en el Incidente. El se incluye en el formulario del OficialCampo Controlador selecciona una respuesta Incidente. El Controlador automáticamente en el asignando recursos al inicialmente, breve incidente (conunacaso de uso AsignarRecursos) al selecciona el respuesta asignando recursos y da un acuse deel caso al informe de incidente (con recibo de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al documentación de atributos y OficialCampo. enviando un mensaje breve al emergencia OficialCampo. responsabilidades únicamente si son Estación 5. El OficialCampo recibe el acuse de recibo y la OficialCampo 5. respuesta seleccionada. el acuse de recibo y la El OficialCampo recibe obvios respuesta seleccionada. una vez que el modelo es estable, la descripción de cada clase será tan detallada como sea posible entrevistas con cliente y usuarios escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 17 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas lista de clases conceptuales candidatas del dominio generada a partir de lista de categorías análisis de lenguaje natural (frases nominales) restringida a los requisitos que se están estudiando actualmente ejemplo: lista de clases candidatas del caso de uso Procesar Venta. Registro EspecificaciónDelProducto Artículo LíneadeVenta Tienda Cajero Venta Cliente Pago Encargado CatálogoDeProductos ... informes: por lo general, no se recogen en el modelo de dominio porque muestran información derivada de otras fuentes, duplicando información. a discutir: ¿es el Recibo una clase conceptual? escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 18 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas error habitual al identificar clases candidatas: considerar como un atributo algo que debería ser un concepto en caso de duda, debe considerarse un concepto separado, puesto que los atributos no deben ser muy habituales en un modelo del dominio NO SI Tienda Venta Venta dirección tienda teléfono En el mundo real, una tienda o un aeropuerto no real, una tienda o un En el mundo se consideran un número o un no se consideran un aeropuerto texto. Estos términos sugieren una entidadEstos términos número o un texto. legal, una organización, yentidad legal, una sugieren una algo que ocupa organización, y algo que ocupa espacio. Por tanto, deben ser un espacio. Por tanto, deben ser un concepto. concepto. Aeropuerto Vuelo Vuelo nombre destino escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 19 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas Si se consumen todos los ObjetoOrdenador,todos los Si se consumen desaparecerá del ObjetoOrdenador : Artículo sistema también su desaparecerá del ObjetoOrdenador, precio, porque Artículo artículoID se encontraba como atributo porque sistema también su precio, en las ObjetoOrdenador : instancias que se eliminaron en las se encontraba como atributo numeroSerie Artículo instancias que se eliminaron cuando se vendieron. descripción ObjetoOrdenador : cuando se vendieron. precio Artículo clases conceptuales de especificación o descripción se utilizan para especificar o describir otras clases una clase EspecificaciónDelArtículo no representa un Artículo, sino una descripción de la información sobre los artículos: aunque se vendan todos los elementos inventariados, eliminándose las correspondientes instancias software de Artículo, permanecerá la EspecificaciónDelArtículo habituales en entornos de gestión (sistemas de compras, ventas, inventarios,...) y fabricación (descripciones de los productos fabricados) se usan cuando: se necesita la descripción de un artículo o servicio independientemente de la existencia actual de algún item de esos artículos o servicios la eliminación de instancias de las cosas que describen provocan pérdida de información que necesitaría mantenerse reduce información redundante o duplicada escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 20 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas NO SI Artículo EspecificaciónDelProducto artículoID desc ribe Artículo numeroSerie descripción precio numeroSerie descripción 1 n artículoID precio Vuelo Vuelo descrit o por DescripcionVuelo fecha fecha numero numero hora 1 n hora n n describe vuelos a vuela a 1 1 Aeropuerto Aeropuerto nombre nombre escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 21 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas reducción del salto en la representación (salto Modelo del Dominio semántico): Vista del personal involucrado de los conceptos más relevantes del dominio una de las grandes ventajas Visualiza los modelos del mundo real. de la tecnología de objetos Venta Pagada-median te Pago reducción de la diferencia fecha cantidad entre el modo en el que el hora 1 1 personal involucrado concibe el dominio y su representación en el software inspira objetos y nombres en el ejemplo: modelo de diseño un pago en el Modelo del Dominio es una clase conceptual (un concepto) Venta un pago en el Modelo de Pago pagada mediant e fecha : Date Diseño es una clase software cantidad : Dinero hora : Tiempo no son lo mismo, pero el 1 1 getDevolucion() : Dinero primero “inspiró” el nombre getTotal() : Dinero y definición del segundo Modelo del Diseño El desarrollador orientado a objetos se ha inspirado en el dominio del mundo real al crear las clases software. Visualiza los componentes software escuela superior de ingenierí

Add a comment

Related presentations

Related pages

Ingeniería del Software

Ingeniería del Software Un Enfoque Práctico. 7ma ed. University of Connecticut. ... Tema 3. Gestión de Proyectos de Software: Gestión ... Tema 2.
Read more

Ingeniería de software - Wikipedia, la enciclopedia libre

... desarrollo del software y de la gestión del ... el desarrollo del software inicial. Alrededor de 2/3 del tiempo ... Ingeniería del software: ...
Read more

Historia de la ingeniería del software - Wikipedia, la ...

El campo era tan nuevo que la idea de gestión por ... El término Ingeniería del software apareció por ... [3] La crisis del software ...
Read more

Ejercicios Tema 3

Ingeniería del Software II ... 1 PROBLEMAS TEMA 3 FUNDAMENTOS DE GESTIÓN DE PROYECTOS ... Ejercicios Tema 3.docx
Read more

Ingeniería del Sofware II Tema 2 Métricas del Software ...

Ingeniería del Sofware II Tema 2 Métricas del Software Fernando ... Gestión de proyectos al iniciar la planeación de un proyecto ...
Read more

INGENIERÍA DEL SOFTWARE III TEMA 4 CONTROL Y GESTIÓN DEL ...

INGENIERÍA DEL SOFTWARE III TEMA 4 CONTROL Y GESTIÓN ... 3: el efecto del defecto ... Medición para la gestión en la Ingeniería del Software. Ra ...
Read more

Ingenieria de Software - YouTube

Ingenieria de Software ... ingenieria software (2 de 3) ... adaptando la ingeniería del software a los negocios
Read more

Ingenieria de software - Monografias.com

Objetivos de la ingeniería de software 3. Competitividad 4. ... 11. Coordinación y Gestión del proyecto. 12. Mediciones y estimaciones 13.
Read more