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

50 %
50 %
Information about Ingeniería del Software de Gestión. Tema 5
Technology

Published on January 18, 2009

Author: kikebar

Source: slideshare.net

Description

Transparencias del Tema 5 (Administración de Proyectos) de la asignatura Ingeniería del Software de Gestión de la Escuela Superior de Ingeniería Informática de la Universidad de Vigo.

tema 6 – administración de proyectos 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 a la administración de proyectos tema 6 - administración de proyectos años 60 y 70: fracaso de muchos grandes proyectos de software retrasos en las entregas, problemas de fiabilidad, costes más elevados de lo previsto, poco eficiente,... motivo principal: enfoque de administración utilizado técnicas de administración derivadas de otras disciplinas de la ingeniería poco efectivas para el desarrollo de software desarrollos profesionales de software imprescindible la administración: restricciones de presupuesto, recursos y calendario responsabilidad del administrador de proyectos planificación y calendario del proyecto supervisión del trabajo (aplicación de estándares) supervisión del progreso (cumplimiento de tiempo y presupuesto) la naturaleza de la ingeniería de software dificulta la administración el producto es intangible: no se puede ver físicamente el progreso del producto no existen procesos de software estándar según tipos de productos proyectos “únicos”: diferencias con proyectos previos, evolución tecnológica de la informática y las comunicaciones,... 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 / 48

actividades de la administración tema 6 - administración de proyectos la administración puede variar mucho según la organización, tipo de producto, etc. actividades responsabilidad de los administradores redacción de propuestas de desarrollo objetivos del proyecto y cómo se va a desarrollar incluye estimaciones de coste, tiempo, asignación a equipos,... planificación y calendario del proyecto: identificación de actividades, hitos y entregas del proyecto estimación económica del proyecto supervisión y revisión del proyecto actividad continua conocimiento del progreso comparación de progreso y coste con lo planificado mecanismos formales e informales selección y evaluación del personal redacción y presentación de informes informes para el cliente, organizaciones contratantes e internos documentos concisos y coherentes presentaciones en las revisiones de progreso administrador: necesidad de comunicación efectiva oral y escrita 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 / 48

actividades de la administración tema 6 - administración de proyectos el administrador tiene tres grandes áreas de actuación personal participantes en el proyecto (ingenieros, programadores, clientes,...) jefes de equipo estructura del equipo de desarrollo problema ámbito del software: función, rendimiento, restricciones, datos de entrada y salida,... descomposición del problema en subproblemas (subsistemas, funciones,...) proceso elección de un modelo de desarrollo controlar la evolución del problema y el proceso descomposición del proceso en actividades y tareas 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 / 48

personal del proyecto tema 6 - administración de proyectos trabajo en grupo: equipos de distintos tamaños (desde 2 a varios cientos) los grandes equipos se dividen en grupos por subproyectos o subsistemas (normalmente de un máximo de ocho) imprescindible espíritu de equipo motivación por el éxito del grupo y por las propias metas personales responsabilidad de los administradores factores que influyen en el trabajo en grupo composición del grupo cohesión del grupo comunicación del grupo organización del grupo 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 / 48

personal del proyecto: composición del grupo tema 6 - administración de proyectos composición del grupo los ingenieros de software tienen una especial motivación por su trabajo ideas propias sobre la resolución de problemas técnicos problemas: ignorar estándares de interfaz, rediseño de sistemas al codificar, embellecimiento innecesario y personal del sistema,... importante seleccionar los miembros correctos para un grupo preferible un grupo con personalidades complementarias que uno seleccionado únicamente por su habilidad técnica INTUITIVO Intuitivo introvertido Intuitivo extrovertido los estilos de trabajo afectan pregunta a otros dice a los otros a la interacción entre clientes, EXTROVERTIDO INTROVERTIDO utiliza sentimientos utiliza sentimientos desarrolladores y usuarios y reacciones y reacciones emocionales emocionales implican la elección de un trabajador para una tarea dada. Por ejemplo: Racional introvertido Racional extrovertido intuitivos prefieren análisis y pregunta a otros dice a los otros diseño (requieren ideas nuevas) al mantenimiento decide lógicamente decide lógicamente (requiere atención a los detalles y análisis de resultados complejos) RACIONAL 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 / 48

personal del proyecto: cohesión del grupo tema 6 - administración de proyectos cohesión del grupo el grupo piensa en sí mismo como un equipo más que como una colección de individuos que trabajan juntos miembros leales al grupo identificados con las metas y con los demás miembros, protegen al grupo de interferencias exteriores esto hace que el grupo sea robusto y se pueda enfrentar a problemas y situaciones inesperadas ventajas se puede desarrollar un estándar de calidad en el grupo los miembros se trabajan de forma cercana, fomentando el aprendizaje mutuo los miembros conocen el trabajo de los demás, lo que facilita la continuidad si un miembro abandona el grupo programación “sin ego”. los programas se consideran propiedad del grupo, no personal factores que influyen en la cohesión cultura organizacional y personalidades del grupo demostrar confianza y facilitar acceso a la información sentido de identidad (nombre y establecimiento de un territorio) involucrados en actividades de grupo (deportes, juegos,...) problemas resistencia al cambio de liderazgo por alguien externo pensamiento de grupo y “corporativismo”: la consideración de alternativas se reemplaza por lealtad a las normas y decisiones del grupo 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 / 48

personal del proyecto: comunicación tema 6 - administración de proyectos comunicación en el grupo importante para el progreso del proyecto factores que influyen tamaño del equipo: hay n(n-1)/2 vínculos de comunicación (n: número de miembros). Unas son bidireccionales y otras unidireccionales, según el estatus estructura del grupo: los grupos informales se comunican de forma más efectiva que los jerárquicos y formales composición del grupo: choques entre miembros con los mismos tipos de personalidad mejor comunicación en grupos de ambos sexos que en grupos de un solo sexo entorno de trabajo físico privacidad (concentración y trabajo sin interrupción) conciencia del exterior (luz natural y vista del entorno exterior) personalización del entorno áreas comunes y de reuniones (formales e informales) 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 / 48

personal del proyecto: organización del grupo tema 6 - administración de proyectos organización del grupo factores que influyen en la estructura más adecuada experiencia y estilos de trabajo de los miembros tamaño del grupo estilos de gestión de clientes y desarrolladores principales tipos de estructura organizativa estructura formal y jerárquica jerarquías claras comunicación vertical asignación de responsabilidades estructura informal estructura democrática y decisiones por consenso tareas asignadas por habilidad y experiencia mejor cohesión y rendimiento ejemplo: “programación extrema” Comparación de estructuras organizativas Fuertemente estructuradas Escasamente estructuradas Proyectos con elevada certeza, estabilidad y Proyectos con incertidumbre (p.e., cambio uniformidad (requieren menos en requerimientos) comunicación) Repetición Necesidad de entrevistas Grandes proyectos Técnicas o tecnologías nuevas Pequeños proyectos 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 / 48

personal del proyecto: organización del grupo tema 6 - administración de proyectos estructura formal: Equipo del Jefe de Programadores, Chief Programmer Team jefe de programadores (JP): responsable del diseño, desarrollo y pruebas de instalación Jefe de los demás informan al JP, quien tiene la última palabra en cada decisión programadores supervisa a los demás, diseña programas, asigna tareas a los otros miembros del equipo otros miembros ayudante JP: apoya al JP y lo reemplaza cuando es Ayudante JP necesario, responsable de la validación del software bibliotecario: da soporte al equipo encargándose de la gestión de configuración (mantenimiento de la documentación, versiones,...), compila, ejecuta pruebas preliminares de módulos y objetos,... Programadores especialistas que trabajan temporal o permanentemente Bibliotecario Administrador expertos en el grupo: programadores especialistas en sistemas operativos Equipo de Programadores pruebas ingenieros de pruebas noveles ... fundamento: grandes diferencias entre habilidades de programación (hasta 25 veces más productivos unos que otros) problemas no abunda el personal adecuado para ser JP (“superprogramador”) problemas de autoestima del resto del equipo los proyectos se resienten si el JP o el ayudante se van modelo difícil de acomodar en las estructuras organizacionales 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 / 48

planificación del proyecto Establecer restricciones Valores iniciales Def inir hitos y tema 6 - administración de proyectos proy ecto parámetros proy ecto productos a entregar Establecer programación en el tiempo del proy ecto la administración efectiva depende de una completa planificación del Iniciar activ idades según la progreso del proyecto programación plan: hilo conductor del proyecto anticipación de los problemas que Esperar un tiempo pueden surgir (entre 2 y 3 semanas) preparación de soluciones a esos problemas Rev isar progreso proy ecto el plan inicial evoluciona según el progreso del proyecto y la disponibilidad de información Rev isar estimaciones de los parámetros enfoque pesimista al elaborar suposiciones y calendario: necesidad de disponer de holguras Actualizar programación existen retrasos Renegociar restricciones y productos a entregar no existen retrasos negociación con éxito negociación sin éxito Iniciar rev isión técnica y posible rev isión proy ecto no completado ni cancelado proy ecto completado o cancelado 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 / 48

planificación del proyecto tema 6 - administración de proyectos plan del proyecto apartados habituales del plan del proyecto 1. introducción: objetivos, restricciones,... 2. organización del proyecto 3. análisis de riesgo: riesgos, probabilidades de que ocurran, estrategias de reducción,... 4. requerimientos de recursos de hardware y software 5. división del trabajo: identificación de actividades, hitos y productos a entregar asociados a cada actividad 6. programa del proyecto: dependencias entre actividades, tiempo estimado para cada hito, asignación de personal a las actividades,... 7. mecanismos de supervisión e informe: descripción de la administración de informes, cuándo deben producirse,... revisión regular durante el proyecto partes que cambian frecuentemente (p.e. calendario) y otras más estables (p.e. presupuesto) organización documental que permita reemplazar fácilmente las secciones otros planes plan de calidad plan de validación plan de administración de la configuración plan de mantenimiento plan de desarrollo del personal 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 / 48

planificación del proyecto tema 6 - administración de proyectos hitos y productos a entregar información a los administradores documentos que describen el estado del software permite juzgar el proceso y actualizar costes y calendario establecimiento de hitos puntos finales de una actividad o tarea del proceso del software documentación que se presenta al administrador: informes cortos de los logros en una actividad representan el fin de una etapa lógica en el proyecto productos a entregar resultado que se entrega al cliente al final de una actividad principal del proceso (análisis, diseño,...) los productos son hitos, pero los hitos no son necesariamente productos a entregar (resultados internos utilizados por el administrador) Estudio Análisis de Desarrollo Estudio Especificación ACTIVIDADES viabilidad requerim. prototipos del diseño requerim. sistema informe requerim. informe diseño requerim. HITOS viabilidad usuarios evaluación arquitectónico sistema PRODUCTO 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 / 48

planificación temporal tema 6 - administración de proyectos calendario dividir el proyecto en actividades estimar el tiempo necesario para realizarlas (algunas se harán en paralelo) los administradores coordinan las actividades organizan el trabajo para optimizar la mano de obra asignan y planifican recursos (personal, hardware, software, presupuesto para viajes,...) duración aconsejable de una actividad: entre 1 y 8 semanas importante tener en cuenta posibles problemas (personal, hardware, software,...) que provocan retrasos problemas previstos: incrementar un 30% la estimación inicial problemas no previstos: incrementar un 20% utilización de diagramas de Gantt y redes de actividades 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 / 48

planificación temporal tema 6 - administración de proyectos RED DE ACTIVIDADES Duración Tarea Dependencias 14/7/02 15 días 15 días (días) M1 T3 T9 T3 T9 8 días 4/8/02 T1 8 hito 5 días 25/8/02 T1 M4 T1 T2 15 4/7/02 T6 M6 25/7/02 T3 15 T1 (M1) INICIO M3 15 días 20 dias T4 10 7 días T2 T7 T11 T11 T5 10 T2,T4 (M2) T6 5 T1,T2 (M3) 25/7/02 5/9/02 10 días 10 días 11/8/02 M8 T4 M2 T5 T7 20 T1 (M1) M7 15 días T8 25 T4 (M5) M5 T10 T12 T12 25 días T9 15 T3, T6 (M4) 18/7/02 10 días T8 T10 15 T5, T7 (M7) FINAL camino crítico 19/9/02 T11 7 T9 (M6) trayectoria más larga en la red de actividad T12 10 T11 (M8) el calendario completo depende de este camino (los retrasos en estas actividades afectan a todo el proyecto) fuente: Ingeniería de Software, I. Sommerville, pp. 80-83 los retrasos en las demás actividades no afectan necesariamente al proyecto 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 / 48

planificación temporal tema 6 - administración de proyectos DIAGRAMA DE GANTT 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 inicio la calendarización inicial será, con T4 toda seguridad, T1 flexibilidad en la fecha de finalización incorrecta. T2 durante el M1 desarrollo se T7 deben comparar las estimaciones T3 previas con las M5 reales para revisar la T8 calendarización M3 del resto del proyecto. M2 al conocer cifras T6 reales, se debe M4 revisar la red de actividades y T9 reorganizar las M7 actividades T10 posteriores para reducir la longitud M6 de la trayectoria T11 crítica. M8 T12 final 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 / 48

planificación temporal tema 6 - administración de proyectos Asignación de personas vs diagrama de Gantt Asignación de personas a actividades 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Tarea Ingeniero Fernando T4 T1 Juana T8 T11 T2 Ana T12 T3 Juana Juana T1 T3 T4 Fernando T9 T5 María T6 Ana Ana T2 T6 T10 T7 Jaime T8 Fernando Jaime T7 T9 Juana T10 Ana María T5 T11 Fernando T12 Fernando El personal no tiene que estar asignado al proyecto todo el tiempo. En los periodos intermedios puede participar en otros proyectos, asistir a cursos de formación, tomar vacaciones,... 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 / 48

medición y métricas del software tema 6 - administración de proyectos “Cuando pueda medir lo que está diciendo y expresarlo con números, ya conoces algo sobre ello; cuando no puedas medir, cuando no puedas expresar lo que dices con números, tu conocimiento es precario y deficiente.” (Lord Kelvin) Métricas cualquier medida relacionada con un sistema, proceso o documentación de software. medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado (IEEE Producto de Proceso de Standard Glossary of Software Engineering, 1993) Producto de Proceso de software software software software Ejemplos: métricas para calcular el tamaño del un producto en líneas de código métricas de la claridad de un párrafo en un texto escrito, por Métricas de Métricas de ejemplo, en un manual (índice de Fog) Métricas de predicciónde Métricas control número de errores localizados en un producto software control predicción entregado número de personas-día necesarias para desarrollar un componente ... Decisiones Decisiones Se aplican a: administrativas administrativas Procesos (métricas de control): por ejemplo, tiempo y esfuerzo medios necesarios para corregir un error. Productos (métricas de predicción): complejidad ciclomática de un módulo, número de métodos y atributos asociados con los objetos de un diseño,... Permiten tomar decisiones 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 / 48

medición y métricas del software tema 6 - administración de proyectos el proceso de medición seleccionar medidas a realizar formular preguntas que la medición intenta responder Elegir medidas definir las métricas requeridas para responder a esas Elegir medidas a realizar preguntas a realizar no se recogen otras métricas que no respondan a esas preguntas seleccionar componentes a valorar Seleccionar Seleccionar no es necesario ni deseable estimar los valores de las componentes a componentes a métricas de todo un sistema de software valorar valorar conjunto representativo componentes críticos y fundamentales (utilización continua) Medir medir características de los componentes Medir características características calcular los valores de las métricas procesando la de los componentes de los componentes representación del componente (diseño, código,...) con herramientas adecuadas identificar componentes anómalos Identificar Identificar medidas comparación de los resultados con mediciones previas medidas anómalas registradas en una base de datos anómalas atención especial a los valores más altos y más bajos pues pueden indicar problemas. analizar componentes con valores anómalos Analizar se examinan los componentes para decidir si los Analizar componentes valores obtenidos indican que su calidad está en componentes anómalos peligro. anómalos no siempre indican problemas (por ejemplo, la complejidad de un módulo puede ser alta pero necesaria) 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 / 48

medición y métricas del software tema 6 - administración de proyectos métricas del producto se refieren a las características del propio software las relaciones entre características del software pueden variar dependiendo de diversos factores (proceso, tecnología de desarrollo, tipo de sistema,...) es necesario construir una base de datos histórica la base de datos se usa para comprobar cómo se relacionan los atributos del producto con la calidad que la organización necesita dos tipos de métricas de producto dinámicas recogidas por las mediciones hechas en un programa en ejecución relación directa con los atributos de calidad del software ejemplo: medición de tiempo de ejecución como medida de la eficiencia del sistema ejemplo: registro del número y tipo de caídas del sistema y relación con la fiabilidad del software estáticas recogidas por las mediciones hechas en las representaciones del sistema (diseño, código, documentación,...) relación indirecta con los atributos de calidad del software ejemplo: longitud del programa como predictor de la mantenibilidad o la complejidad ejemplo:índice de Fog como predictor de la facilidad de comprensión de un documento de texto 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 / 48

medición y métricas del software tema 6 - administración de proyectos Ejemplos de métricas estáticas del producto métrica de descripción producto fan-in: medida del número de funciones que llaman a otra función X fan-out: número de funciones que son llamadas por una función X. Un valor alto de fan-in indica que X está fuertemente acoplada al resto del diseño fan-in / fan-out y que los cambios en X pueden tener efectos extensivos al resto del sistema. Un valor alto de fan-out indica que la complejidad de X podría ser excesiva, debido a la complejidad de la lógica de control necesaria para coordinar los componentes llamados. Medida del tamaño del programa en líneas de código (LDC). Cuanto mayor sea el longitud del código tamaño de un componente, más complejo y susceptible de incorporar errores será. complejidad Medida de la complejidad del control de un programa, y está relacionada con la ciclomática comprensión del programa. Medida de la longitud promedio de los diferentes identificadores de un programa. longitud de los Cuanto mayor sea esta longitud, más probable es que tengan significado, y por identificadores tanto el programa será más comprensible. Medida de la profundidad de anidamiento de las instrucciones if en un programa. profundidad de los if Instrucciones if profundamente anidadas son difíciles de comprender y son anidados potencialmente susceptibles a errores. Medida de la longitud promedio de las palabras y declaraciones en los índice de Fog documentos. Cuanto mayor sea el índice de Fog, más difícil será comprender el documento. 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 / 48

medición y métricas del software tema 6 - administración de proyectos 1 R1 Complejidad ciclomática 2 V(G) = 4 3 4 Número de regiones = 4 R2 11 aristas – 9 nodos = 4 5 6 R3 7 8 R4 9 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 22 / 48

medición y métricas del software tema 6 - administración de proyectos métricas orientadas a objetos: métricas CK (Chidamber y Kemerer) métrica descripción asumen que se definen n métodos con complejidad c1, c2,...cn se definen para la clase C. La métrica de complejidad específica que se haya elegido (por ejemplo, la complejidad ciclomática) debe normalizarse de manera que la complejidad nominal para un método toma un valor de 10. métodos ponderados MPC = Σci para cada i=1 hasta n por clase (MPC) El número de métodos y su complejidad indican la cantidad de esfuerzo para implementar y verificar una clase. Cuanto mayor sea el número de métodos, más complejo es el árbol de herencia. Además, a medida que crece el número de métodos para una clase dada, más específica se vuelve y, por lo tanto, menos reutilizable. Por eso, el MP debe mantenerse lo más bajo posible. longitud máxima del nodo a la raíz del árbol. Cuanto mayor sea, las clases de los niveles más bajos heredarán muchos métodos, lo que conlleva dificultades profundidad del árbol potenciales al predecir el comportamiento de una clase. Además, la complejidad de herencia (PAH) de diseño será mayor. Sin embargo, valores de APH grandes indican mayor capacidad de reutilización de métodos. número de hijos cuantos más descendientes, más reutilización, pero también es posible que (NDH) algunos descendientes no sean miembros realmente apropiados de la superclase. acoplamiento entre es el número de colaboraciones de una clase, y cuanto mayor sea, menor será el clases (AEC) grado de reutilización, además de complicarse las pruebas y el mantenimiento. número de métodos que pueden ser ejecutados en respuesta a un mensaje respuesta para una recibido por un objeto de esa clase. Cuanto mayor sea RPC, mayor esfuerzo se clase (RPC) requiere para su comprobación, y más complejo es el diseño. carencia de cohesión dos métodos son similares si comparten al menos un atributo de la clase. A en los métodos (CCM) mayor número de métodos similares, mayor cohesión hay en la clase. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departament

Add a comment

Related presentations

Related pages

tema 5 - Informática de Gestión Ingeniería del Software ...

Unformatted text preview: Informática de Gestión Ingeniería del Software Agenda Qué es IS Motivación Problemas Objetivos Situación Actual Visión ...
Read more

Tema 5: Gestión de Proyectos Software Métricas

Ingeniería del Software de Gestión III Tema 5: Gestión de Proyectos Software Métricas. ... • Ejemplos de entidades en ingeniería software: recurso, ...
Read more

Tema 5: Gestión de Proyectos Software Estimación - lsi.us.es

Ingeniería del Software de Gestión III Tema 5: Gestión de Proyectos Software Estimación. Índice ... Añadir 5 % de reuniones y 15 % de gestión
Read more

Ingeniería de software - Wikipedia, la enciclopedia libre

La Ingeniería del software viene a ... el tema principal que motiva el inicio del estudio y ... desarrollo del software y de la gestión ...
Read more

Tema 3 Metodologías de Desarrollo de Software

Ingeniería del Software Ingeniería del Software de Gestión Tema 3 ... Metodologías de Desarrollo de Software 5
Read more

tema 2 -administración de proyectos - wamis.org

ingeniería del software de gestión ... tema 2 -administración de proyectos ... • Band C (5.6 Ghz frequency, ...
Read more

TEMA 5. SEGUIMIENTO DE PROYECTOS: CONTROL DE CALIDAD ...

TEMA 5. SEGUIMIENTO DE ... Calidad Objetivo primordial de la Ingeniería del software: ... La función de la gestión de riesgos del software es ...
Read more

| TEMA 5 | PROGRAMACIÓN EXTREMA (XP) | Ingenieria de Software

... TEMA 5 | PROGRAMACIÓN ... ligera que controla los riesgos que hay en la creación del software, ... Ingeniería de software: Un enfoque práctico ...
Read more

Ingenieria de software - Monografias.com

Objetivos de la ingeniería de software. ... Coordinación y Gestión del proyecto. ... 5. Método del ciclo de vida clásico.
Read more