Conferencia Gestión de Proyectos de TI
description
Transcript of Conferencia Gestión de Proyectos de TI
![Page 1: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/1.jpg)
Gestión de Proyectos de TIGestión de Proyectos de TIExp. Hanz Cocchi GuerreroIT Project ManagerExp. Hanz Cocchi GuerreroIT Project Manager
![Page 2: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/2.jpg)
2Gestión de Proyectos de TI
AgendaAgenda
¿Que es un Proyecto?Problemas con el Software.¿Que son los riesgos?¿Qué deberíamos hacer?Seis mejores prácticas.
¿Que es un Proyecto?Problemas con el Software.¿Que son los riesgos?¿Qué deberíamos hacer?Seis mejores prácticas.
![Page 3: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/3.jpg)
3Gestión de Proyectos de TI
CostosTiempo
sCalidad
Es un proceso temporal que tiene un inicio y fin. Su resultado es un producto o servicio único. Esta constituido por un conjunto de actividades interrelacionadas
que se desarrollan por una sola vez, que constituyen una inversión para el negocio
Tiene objetivos, alcances y productos entregables específicos y un programa y presupuesto definidos.
Existen proyectos De Tecnologías de la Información y de e-Business, Desarrollo interno, Desarrollo por terceros, Evaluación e implantación de paquetes, De Soporte Técnico, Adquisición e instalación de hardware/software, Redes y/o comunicaciones
Se controla :
Es un proceso temporal que tiene un inicio y fin. Su resultado es un producto o servicio único. Esta constituido por un conjunto de actividades interrelacionadas
que se desarrollan por una sola vez, que constituyen una inversión para el negocio
Tiene objetivos, alcances y productos entregables específicos y un programa y presupuesto definidos.
Existen proyectos De Tecnologías de la Información y de e-Business, Desarrollo interno, Desarrollo por terceros, Evaluación e implantación de paquetes, De Soporte Técnico, Adquisición e instalación de hardware/software, Redes y/o comunicaciones
Se controla :
¿Qué es un proyecto?¿Qué es un proyecto?
![Page 4: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/4.jpg)
4Gestión de Proyectos de TI
Alarmante ProblemaAlarmante Problema
Solución Enfoque integral del ciclo de vida Técnicas formales y herramientas Ingeniería de software
Solución Enfoque integral del ciclo de vida Técnicas formales y herramientas Ingeniería de software
71% de todos los proyectos fallan, ya sea que se han excedido el presupuesto o empiezan a funcionar después del plazo original. Cada año, 75 millones de dólares se pierden por fallas de los proyectos en los
Estados Unidos
Fuente: The Standish Group 2001Fuente: The Standish Group 2001 Demanda insatisfecha
Plazos y costos excedidos Insuficiente productividad Calidad inadecuada
Causas Naturaleza del software Inadecuado enfoque gerencial Carencia de tecnología
Demanda insatisfecha Plazos y costos excedidos Insuficiente productividad Calidad inadecuada
Causas Naturaleza del software Inadecuado enfoque gerencial Carencia de tecnología
![Page 5: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/5.jpg)
5Gestión de Proyectos de TI
Porque fracasa el proyecto?Porque fracasa el proyecto?
Como lo explicó el
cliente
Como lo entendió el
líder del proyecto
Como lo diseñó el analista
Como lo escribió el
programador
Como lo recibieron los probadores
beta
Como lo describió el Consultor de
Negocios
![Page 6: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/6.jpg)
6Gestión de Proyectos de TI
Porque fracasa el proyecto?Porque fracasa el proyecto?
Como se documentó
Las operaciones instaladas
Lo que se le cobró al Cliente
El soporte que se le
dio
Como se comercializó
Lo que el cliente realmente necesitaba
![Page 7: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/7.jpg)
7Gestión de Proyectos de TI
Lo que el cliente realmente necesitaba
No se comprendieron las necesidades del usuario No se previó el impacto de los requerimientos de
cambios Se descubrieron muy tarde falencias graves en el
Proyecto Hay módulos que no se pueden integrar Interferencias entre los miembros del equipo No cumplen sus objetivos Se exceden considerablemente en el tiempo Se exceden de su presupuesto
No se comprendieron las necesidades del usuario No se previó el impacto de los requerimientos de
cambios Se descubrieron muy tarde falencias graves en el
Proyecto Hay módulos que no se pueden integrar Interferencias entre los miembros del equipo No cumplen sus objetivos Se exceden considerablemente en el tiempo Se exceden de su presupuesto
¿Por qué fracasó?¿Por qué fracasó?
![Page 8: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/8.jpg)
8Gestión de Proyectos de TI
¿Qué es un riesgo del proyecto?¿Qué es un riesgo del proyecto?
Cualquier factor que puede interferir en terminación exitosa del proyecto
Es reconocer que un problema puede suceder Fases del análisis del riesgo
Identificación del riesgo Análisis y cuantificación Plan de mitigación Asignar responsables
Cualquier factor que puede interferir en terminación exitosa del proyecto
Es reconocer que un problema puede suceder Fases del análisis del riesgo
Identificación del riesgo Análisis y cuantificación Plan de mitigación Asignar responsables
![Page 9: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/9.jpg)
9Gestión de Proyectos de TI
Análisis de RiesgoAnálisis de Riesgo
Estimación del riesgo Establecer una escala que refleje la probabilidad
observada de riesgo. Bastante improbable Improbable Moderado Probable Bastante probable
Impacto (pesos) Estimación del impacto de riesgo en el proyecto
Cálculo de riesgoConsiderar (riesgo, probabilidad de riesgo, impacto)
Estimación del riesgo Establecer una escala que refleje la probabilidad
observada de riesgo. Bastante improbable Improbable Moderado Probable Bastante probable
Impacto (pesos) Estimación del impacto de riesgo en el proyecto
Cálculo de riesgoConsiderar (riesgo, probabilidad de riesgo, impacto)
![Page 10: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/10.jpg)
10Gestión de Proyectos de TI
¿Qué se debería hacer?¿Qué se debería hacer?
Defina el alcance del proyecto.Utilice métricas en su proyecto.
¿Cuánto pesa el software?Gestione los riesgos con anticipación.Use una metodología probada.Modele las amenazas de su proyecto.Use herramientas de Verificación de
código.Haga pruebas exhaustivas.
Defina el alcance del proyecto.Utilice métricas en su proyecto.
¿Cuánto pesa el software?Gestione los riesgos con anticipación.Use una metodología probada.Modele las amenazas de su proyecto.Use herramientas de Verificación de
código.Haga pruebas exhaustivas.
![Page 11: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/11.jpg)
11Gestión de Proyectos de TI
![Page 12: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/12.jpg)
12Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
![Page 13: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/13.jpg)
13Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
![Page 14: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/14.jpg)
14Gestión de Proyectos de TI
Administrar los requerimientosAdministrar los requerimientos
Requirements Management, enfoque sistemático que involucra: Obtener, organizar y documentar la
funcionalidad y restricciones requeridas a un sistema
Analizar los cambios solicitados y evaluar impactos
Registrar y documentar las alternativas y decisiones tomadas
Área Clave de Proceso para CMM nivel 2
Requirements Management, enfoque sistemático que involucra: Obtener, organizar y documentar la
funcionalidad y restricciones requeridas a un sistema
Analizar los cambios solicitados y evaluar impactos
Registrar y documentar las alternativas y decisiones tomadas
Área Clave de Proceso para CMM nivel 2
![Page 15: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/15.jpg)
15Gestión de Proyectos de TI
Administrar los requerimientosAdministrar los requerimientos
Los requerimientos pueden ser adecuadamente capturados y comunicados a través de Casos de Uso
Los Casos de Uso son importantes instrumentos de planificación
Los requerimientos pueden ser adecuadamente capturados y comunicados a través de Casos de Uso
Los Casos de Uso son importantes instrumentos de planificación
Modelo de DiseñoModelo de Implementación Modelo de Test
verificaRealización influenciados porLos Casos de Uso
direccionan el trabajo desde el análisis hasta el
test
Modelo de Casos de Uso
![Page 16: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/16.jpg)
16Gestión de Proyectos de TI
Administrar los requerimientosAdministrar los requerimientos
Las comunicaciones están basadas en requerimientos bien definidos
Los requerimientos pueden ser priorizados, filtrados y monitoreados
Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto
Las inconsistencias se detectan fácilmente Con herramientas adecuadas: repositorio de
requerimientos, con atributos y relaciones
Las comunicaciones están basadas en requerimientos bien definidos
Los requerimientos pueden ser priorizados, filtrados y monitoreados
Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto
Las inconsistencias se detectan fácilmente Con herramientas adecuadas: repositorio de
requerimientos, con atributos y relaciones
![Page 17: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/17.jpg)
17Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
![Page 18: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/18.jpg)
18Gestión de Proyectos de TI
PlaneamientoPlaneamientoInicialInicial
PlaneamientoPlaneamiento
RequerimientosRequerimientosAnálisis y DiseñoAnálisis y Diseño
ImplementaciónImplementación
PruebaPrueba
DistribuciónDistribución
EvaluaciónEvaluación
Ambiente deAmbiente deAdministraciónAdministración
Desarrollar Software IterativamenteDesarrollar Software Iterativamente
Cada iteración resulta en un release ejecutable
Cada iteración resulta en un release ejecutable
![Page 19: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/19.jpg)
19Gestión de Proyectos de TI
Desarrollar Software IterativamenteDesarrollar Software Iterativamente
Los desentendimientos importantes se evidencian tempranamente
Se alienta el feedback del usuario Focalización en los temas más críticos, sin
distracciones Testing continuo e iterativo: evaluación
objetiva Inconsistencias entre requerimientos,
diseños e implementaciones se detectan tempranamente
Los desentendimientos importantes se evidencian tempranamente
Se alienta el feedback del usuario Focalización en los temas más críticos, sin
distracciones Testing continuo e iterativo: evaluación
objetiva Inconsistencias entre requerimientos,
diseños e implementaciones se detectan tempranamente
![Page 20: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/20.jpg)
20Gestión de Proyectos de TI
Desarrollar Software IterativamenteDesarrollar Software Iterativamente
Carga de trabajo mejor repartida en el tiempo
El equipo puede analizar las lecciones aprendidas en las primeras iteraciones
Integración progresiva en lugar de Big Bang Se facilita la reutilización Arquitectura más robusta
Carga de trabajo mejor repartida en el tiempo
El equipo puede analizar las lecciones aprendidas en las primeras iteraciones
Integración progresiva en lugar de Big Bang Se facilita la reutilización Arquitectura más robusta
![Page 21: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/21.jpg)
21Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar Requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
![Page 22: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/22.jpg)
22Gestión de Proyectos de TI
Verificar la Calidad del SoftwareVerificar la Calidad del Software
La actividad fundamental de esta práctica es el testing
Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance
La actividad fundamental de esta práctica es el testing
Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance
Desarrollo Implementación
Costo
Encontrar y reparar un problema de software después de la implementación puede resultar de 100 a 1000 veces más costoso
![Page 23: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/23.jpg)
23Gestión de Proyectos de TI
Verificar la Calidad del SoftwareVerificar la Calidad del Software
La evaluación del estado del proyecto es objetiva, se evalúan resultados de test.
Se exponen inconsistencias en requerimientos, diseños e implementaciones
Se focaliza en las áreas de riesgo más alto Los defectos se identifican en forma temprana Existen herramientas automatizadas para el testing
de funcionalidad, confiabilidad y performance.
La evaluación del estado del proyecto es objetiva, se evalúan resultados de test.
Se exponen inconsistencias en requerimientos, diseños e implementaciones
Se focaliza en las áreas de riesgo más alto Los defectos se identifican en forma temprana Existen herramientas automatizadas para el testing
de funcionalidad, confiabilidad y performance.
![Page 24: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/24.jpg)
24Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
Verificar Calidad
![Page 25: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/25.jpg)
25Gestión de Proyectos de TI
Diseñar el procesoDiseñar el proceso
Logical DesignLogical DesignConceptual DesignConceptual Design
ScenariosPhysical DesignPhysical Design
Components,User Interface, and Physical Database
Objects and Services,User Interface, and Logical Database
![Page 26: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/26.jpg)
26Gestión de Proyectos de TI
Modelar Software VisualmenteModelar Software Visualmente
Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementación
Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementación
Código
Clases
Subsistemas
El Modelamiento Visual
eleva el nivel de abstracción
![Page 27: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/27.jpg)
27Gestión de Proyectos de TI
Modelar Software VisualmenteModelar Software Visualmente
Los casos de uso permiten especificar comportamiento sin ambigüedades
Quedan expuestas las arquitecturas inflexibles o no modulares
El diseño refleja sus inconsistencias más rápidamente
Existen herramientas que proveen soporte para la modelamiento visual
Los casos de uso permiten especificar comportamiento sin ambigüedades
Quedan expuestas las arquitecturas inflexibles o no modulares
El diseño refleja sus inconsistencias más rápidamente
Existen herramientas que proveen soporte para la modelamiento visual
![Page 28: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/28.jpg)
28Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
![Page 29: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/29.jpg)
29Gestión de Proyectos de TI
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes
La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software selección de los elementos estructurales, y sus
interfaces, por los cuales el sistema está compuesto
comportamiento, especificado como colaboraciones entre los elementos
composición en subsistemas de los elementos estructurales y de comportamiento
estilo de arquitectura que guía a la organización
La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software selección de los elementos estructurales, y sus
interfaces, por los cuales el sistema está compuesto
comportamiento, especificado como colaboraciones entre los elementos
composición en subsistemas de los elementos estructurales y de comportamiento
estilo de arquitectura que guía a la organización
![Page 30: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/30.jpg)
30Gestión de Proyectos de TI
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes
Vista Lógica
Usuario Funcionalidad
Vista de Implementación
Programadores Administración del Software
Vista del Proceso
PerformanceEscalabilidadRendimiento
Integradores
Vista de Desarrollo
Topología Distribución, Instalación
Comunicación
Ingeniería
Conceptual Physical
Vista de Caso de Uso
![Page 31: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/31.jpg)
31Gestión de Proyectos de TI
System-System-softwaresoftware
MiddlewareMiddleware
NegocioNegocio
AplicaciónAplicación
Arquitectura basada en
componentes
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes Un componente de software puede definirse como
una pieza no trivial de software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida
Realización física de una abstracción en el diseño
Un componente de software puede definirse como una pieza no trivial de software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida
Realización física de una abstracción en el diseño
![Page 32: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/32.jpg)
32Gestión de Proyectos de TI
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes Definir arquitecturas muy modulares e identificar,
aislar, diseñar, desarrollar y probar componentes bien formados
Desarrollar componentes para ser reutilizados. Formar la base de rehúso de la organización
Industria de infraestructura de componentes COM+ - Microsoft Component Object Model CORBA - Common Object Request Broker
Architecture - OMG JavaBeans – SUN Assemblys .NET Servicios Web
Definir arquitecturas muy modulares e identificar, aislar, diseñar, desarrollar y probar componentes bien formados
Desarrollar componentes para ser reutilizados. Formar la base de rehúso de la organización
Industria de infraestructura de componentes COM+ - Microsoft Component Object Model CORBA - Common Object Request Broker
Architecture - OMG JavaBeans – SUN Assemblys .NET Servicios Web
![Page 33: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/33.jpg)
33Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar Requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
![Page 34: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/34.jpg)
34Gestión de Proyectos de TI
Controlar los Cambios al SoftwareControlar los Cambios al Software Controlar, registrar y monitorear los cambios para posibilitar
el desarrollo iterativo Establecer “workspaces” seguros para cada desarrollador Automatizar la integración y la administración de “builds”
Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo
Establecer “workspaces” seguros para cada desarrollador Automatizar la integración y la administración de “builds”
ALERTREPORT
Workspacede Administración
Integración
Desarrollo en paralelo
Administración del Build
CM es mucho más que check-in y check-out
![Page 35: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/35.jpg)
35Gestión de Proyectos de TI
Controlar los Cambios al Software: BeneficiosControlar los Cambios al Software: Beneficios
Las solicitudes de cambios formales facilitan la claridad de comunicación
Los espacios de trabajo aislados reducen la interferencia entre los miembros del equipo que trabajan en paralelo
Las estadísticas de cantidad de cambios proveen buenas métricas para evaluar objetivamente el estado del proyecto
La propagación del cambio es evaluable y controlable
Los cambios pueden ser mantenidos en sistemas automáticos
Las solicitudes de cambios formales facilitan la claridad de comunicación
Los espacios de trabajo aislados reducen la interferencia entre los miembros del equipo que trabajan en paralelo
Las estadísticas de cantidad de cambios proveen buenas métricas para evaluar objetivamente el estado del proyecto
La propagación del cambio es evaluable y controlable
Los cambios pueden ser mantenidos en sistemas automáticos
![Page 36: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/36.jpg)
36Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar Requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelizarVisualmente
![Page 37: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/37.jpg)
37Gestión de Proyectos de TI
Preguntas!????Preguntas!????
![Page 38: Conferencia Gestión de Proyectos de TI](https://reader033.fdocumento.com/reader033/viewer/2022051513/547bf89f5906b56d798b4681/html5/thumbnails/38.jpg)
38Gestión de Proyectos de TI
ReferenciasReferencias
•El ciclo de vida de desarrollo de Seguridad http://www.microsoft.com/spanish/msdn/articulos/archivo/030505/voices/sdl.mspx
•Ingeniería de Softwarehttp://www.ingenierosoftware.com/
•Contrato para desarrollo de Softwarehttp://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5003/desarrol.htm