Administración n de Proyectos de Software
|
|
- María Ángeles Quiroga Márquez
- hace 8 años
- Vistas:
Transcripción
1 Administración n de Proyectos de Software 1.Introducci Introducción n y conceptos básicosb Conceptos básicos: b proyecto y su administración
2 Algunas preguntas guía Qué es un proyecto? Es diferente un proyecto de software? Necesita administrarse un proyecto? Qué se hace para administrar un proyecto? Proyectos de software
3 I. Qué se entiende por proyecto de software? Proyecto Planta y disposición que se forma para un tratado o para la ejecución de una cosa de importancia Designio de ejecutar algo Conjunto de escritos, dibujos y cálculos hechos para dar idea de lo que ha de ser y costar una obra de ingeniería o arquitectura Diccionario Léxico Hispano, W.M. Jackson, Inc. Editores Características clave de un proyecto (1/2) 1. Involucra tareas no rutinarias 2. Requieren planeación 3. Se deben lograr objetivos o crear productos específicos 4. Tiene un lapso de tiempo específico predefinido Hughes y Cotterell, Software Project Management, McGraw-Hill, Secciones 1.2
4 Características clave de un proyecto (2/2) 5. El trabajo se lleva a cabo por otras personas 6. Involucra varias especializaciones 7. Los trabajos se llevan a cabo en varias fases 8. Los recursos son limitados 9. Los proyectos son largos o complejos Hughes, B. y Cotterell, M., Software Project Management, McGraw-Hill, Secciones 1.2 y 1.3 Ejercicio 1 Cuál de los siguientes puede considerarse proyecto? Producir la edición de un periódico Hacer un túnel bajo el mar Realizar un matrimonio Hughes, B. y Cotterell, M., Software Project Management, McGraw-Hill
5 Características de los proyectos de software Invisibilidad. El avance dentro de un proyecto de construcción de una carretera o puente puede ser visto, mientras que en el software no es inmediatamente visible. Complejidad Los proyectos de software contienen mayor complejidad que otros tipos de proyectos respecto al dinero gastado Flexibilidad El software puede cambiarse más fácilmente que otros productos Hughes, B. y Cotterell, M., Software Project Management, McGraw-Hill, Secciones 1.3 Proyectos de software versus otros tipos de proyectos Muchas técnicas aplicables a la administración de proyectos son aplicables a la administración de proyectos de software. Sin embargo: los productos de proyectos de software tienen ciertas características que los hacen diferentes. Una forma de percibir la administración de proyectos de software es haciendo visible lo que es invisible Hughes, B. y Cotterell, M., Software Project Management, McGraw-Hill, Secciones 1.3
6 Proyecto No todos los proyectos son iguales Un proyecto es como viajar en carretera. Algunos proyectos son simples y rutinarios, como conducir hacia la tienda a plena luz del día. Pero la mayoría de los proyectos que valen la pena realizar son más parecidos a conducir un camión, en la montaña, de noche en Nepal (Cem Kamer, James Bach y Bret Pettichord) Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Administración n de proyectos
7 Administración 1. Planear: decidir qué se va a hacer 2. Organizar: hacer preparativos 3. Asignar personal: elegir personas adecuadas 4. Dirigir: dar órdenes 5. Monitorear: observar el progreso 6. Controlar: emprender acciones para corregir problemas de funcionamiento 7. Innovar: proponer soluciones novedosas 8. Representar: conectar con clientes y usuarios Hughes, B. y Cotterell, M., Software Project Management, McGraw-Hill Administración vista de administradores Enfrentar fechas límite Enfrentar limitaciones en recursos Comunicar efectivamente a los diversos grupos Conseguir que todos se comprometan Establecer hitos medibles Enfrentar cambios Lograr plan de acuerdo con desarrolladores Ganar compromiso de gerencia Enfrentar conflictos Negociar con vendedores y subcontratistas
8 Problemas comunes en proyectos según n administradores Estimaciones y planes deficientes Falta de estándares y medidas de calidad Falta de guía sobre toma de decisiones en organización Falta de técnicas para hacer visible el progreso Papeles y responsabilidades mal definidos Problemas comunes en proyectos según n personal Trabajo definido de modo inadecuado Administradores ignorantes de tecnología informática Falta de conocimiento del área de aplicación Falta de estándares Documentación inadecuada Retraso de actividades precedentes Falta de comunicación con usuarios Trabajo duplicado por mala comunicación
9 Problemas comunes en proyectos según n personal Falta de compromiso Hay un solo interesado y se va Conocimiento muy especializado Cambio de ambiente de software Cambio de requerimientos Presión de fecha límite Falta de control de calidad Falta de entrenamiento Administración lejana Información y control Decisiones: estratégicas (objetivos), tácticas (alcanzar metas) operativas (día con día) Información: medidas de actuación medidas predictivas control fluye información fluye EMPRESA
10 Administración n de Proyectos (1/2) Necesaria si se quiere obtener un producto en tiempo y forma Es el arte de dirigir y coordinar los recursos humanos y materiales a lo largo de la vida de un proyecto por medio de técnicas modernas de administración, para lograr los objetivos en: alcance, costo, tiempo, calidad y satisfacción. Administración n de Proyectos (2/2) Aunque el administrador de software realiza lo mismo que cualquier administrador, pero resulta más difícil debido a: El producto es intangible No existen procesos de software estándar A menudo los proyectos grandes de software son únicos Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección 4.1
11 Ejercicio 2 Explique por qué la intangibilidad de los sistemas de software plantea problemas para la administración de proyectos de software. Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley Actividades de la Administración de Proyectos de Software Redacción de la propuesta Planeación y calendarización del proyecto Costeo del proyecto Supervisión y revisión del proyecto Selección y evaluación del personal Redacción y presentación de información Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección 4.1
12 1. Redacción n de la propuesta La redacción de la propuesta deberá incluir: Objetivos del proyecto Cómo se llevará a cabo Costos y calendarización Justificación del por qué se entregará a un equipo u organización Resulta crítica pues la habilidad de realizar la redacción sólo se adquiere con el tiempo. Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección Planeación n y calendarización del proyecto Se refiere a la identificación de: Actividades Hitos Entregas producidas por un proyecto Por lo que se debe bosquejar un plan de desarrollo hacia las metas del proyecto Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección 4.1
13 3. Costeo del proyecto Actividad que se refiere al estimado de recursos que se requieren para llevar a cabo el proyecto. Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección Supervisión n y revisión n del proyecto Actividad continua Se lleva un control de los avances de los costos y progresos reales versus los planeados Pueden apoyarse en mecanismos formales El administrador debe detectar la realidad después de entrevistarse con el personal del proyecto Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección 4.1
14 5. Selección n y evaluación n del personal El administrador debe emplear a la gente ideal para el proyecto. Sin embargo en ocasiones se presentan problemas como: Bajo presupuesto para contratar personal calificado El personal adecuado no está disponible La empresa desea que su personal novato obtenga experiencia Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección Redacción n y presentación n de información El administrador debe dar informes al cliente y a su organización Los reportes de avance deben ser concisos y coherentes. Debe saber comunicarse con el cliente Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección 4.1
15 Un administrador de proyectos de software debe tener la habilidad de comunicarse efectivamente de forma oral y escrita Sommerville, I., Ingeniería de Software, 6ª ed., Addison Wesley, Sección 4.1 Las cuatro P
16 Elementos que intervienen en la Administración n de Proyectos La efectividad de la administración de proyectos se enfoca en las cuatro P Personal: Quiénes? Producto: Qué? Proceso: Cómo? Proyecto: Para qué? Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Personal -1- El software lo hacen seres humanos Para seres humanos Y a veces afecta a otros seres humanos Así lo más importante en el software son los seres humanos (personas)
17 Producto -2- Lo que desea obtenerse al final del proyecto A veces se detalla en entregables (partes del producto a lograr) Proceso -3- Un proceso de software proporciona un marco de trabajo para establecer el plan detallado para el desarrollo del software Puede ser simplemente un método o una metodología Una forma de hacer las cosas Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
18 Proyecto -4- Lo que se desea emprender, para ciertas personas, empleando un equipo de personas específico, para obtener un producto deseado y usando un proceso adecuado. Personal -1-
19 Personal La componente más importante para el éxito de un proyecto es el factor humano Estudio realizado por IEEE en 1988 A pesar de la importancia del ser humano, los gerentes ignoran el desarrollo de su personal. Aspectos a considerar referentes al factor humano Participantes Líderes de equipo Estructura organizacional del equipo de software Conflictos de coordinación y comunicación Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Participantes (1/2) Gestores ejecutivos Definen aspectos del negocio que influenciará al proyecto Gestores técnicos Planifican, motivan, organizan y controlan a los profesionales Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
20 Participantes (2/2) Profesionales Proporcionan las habilidades técnicas para la ingeniería de un producto Clientes Especifican los requerimientos para la IS Usuarios finales Interactúan con el software una vez que se libera Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Líderes de equipo Los profesionales de computación, generalmente, no tiene las competencias para ser líderes, las adquieren por necesidad. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
21 Líderes de equipo Jerry Weinberg, 1986: Sugiere que los líderes de proyecto exitosos aplican un estilo de gestión de resolución de problemas. Entender el problema, gestionar el flujo de ideas y, al mismo tiempo, hacer que el equipo se comprometa con la calidad. Propone que para lograr un buen liderazgo se use el modelo MOI Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Modelo MOI para el liderazgo Motivación. Habilidad para alentar al personal a producir según su mejor capacidad. Organización. Habilidad para adecuar procesos existentes o inventar nuevos. Ideas e innovación. Habilidad para alentar a la gente a ser creativo y trabajar dentro de los límites establecidos para la aplicación. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
22 Estructura organizacional del equipo de software En una organización existen prácticas y políticas que no son responsabilidad del administrador de proyectos de software, pero sí es su responsabilidad la organización de los equipos desarrolladores de software. La forma de organización de los equipos depende de varios factores. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Factores relevantes en la elección de organización n de un equipo de software Factores de Mantei 1. Dificultad del problema que se resolverá 2. Tamaño del problema resultante (en líneas de código o puntos de función). 3. Tiempo en que el equipo estará junto (vida del equipo) 4. Grado de modularización 5. Calidad y confiabilidad requeridos para el sistema 6. Rigidez de la fecha de entrega 7. Grado de sociabilidad (comunicación) que requiere el sistema Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
23 Paradigmas organizacionales para los equipos de Ingeniería a de Software (1/2) Constantine sugiere cuatro, en 1993: 1. Paradigma cerrado. Tipo jerárquico, funcionan bien en proyectos similares a los que ya se han hecho antes. 2. Paradigma aleatorio. Se organizan como ellos se acomoden y funcionan bien en proyectos innovadores o de adelantos tecnológicos. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Paradigmas organizacionales para los equipos de Ingeniería a de Software (2/2) 1. Paradigma abierto. Combinación de los anteriores, funcionan bien para problemas complejos, pero no eficientemente. 2. Paradigma sincrónico. Se apoya en la compartimentalización natural de un problema y organiza a los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
24 Equipos Ágiles Los métodos ágiles subrayan la competencia individual en conjunción con la colaboración del grupo Para aprovechar la competencia de cada miembro del equipo y fomentar la colaboración eficaz a lo largo del proyecto, los equipos ágiles son auto organizados La planificación se mantiene al mínimo Se realizan reuniones periódicas de equipos para coordinar el trabajo que se debe hacer Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Toxicidad de equipo No todos los equipos funcionan bien (no cuajan) Jackman en 1998, propone cinco factores que fomentan un ambiente de equipo tóxico: Atmósfera de trabajo frenética. Alta frustración que provoca fricciones Proceso de software fragmentado o pobremente coordinado Poca definición de los papeles dentro del equipo Continuas y repetidas exposiciones al fracaso Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
25 Cómo evitar la Toxicidad de equipo Toxina 1. Atmósfera de trabajo frenética. 2. Alta frustración que provoca fricciones 3. Proceso de software fragmentado o pobremente coordinado 4. Poca definición de los papeles dentro del equipo 5. Continuas y repetidas exposiciones al fracaso Prevención 1. Toda la información del proyecto debe estar a la mano y no debe cambiarse. 2. Dar a los miembros del equipo la misma responsabilidad. 3. Comprender el problema y que el equipo elija el proceso. 4. Establecer la forma de revisar los avances y su calidad (RTF) 5. Establecer técnicas de equipo para realimentación y resolución de problemas. Conflictos de coordinación n y comunicación La escala de muchos esfuerzos de desarrollo es muy grande La incertidumbre es común La interoperabilidad con otros sistemas Para minimizar los conflictos Se deben establecer mecanismos para la comunicación formal e informal entre los miembros del equipo y entre múltiples equipos. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
26 Ejercicio 3 Proponga 10 lineamientos para que el ingeniero de Software ejerza su potencial completo en su trabajo. Los 10 mandamientos del Ingeniero de Software Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill Manejo de personal (I. Sommerville) Notas por Juan Manuel Fernández ndez Peña 2011
27 Factores críticos Objetividad Trato equitativo, transparente Respeto Aceptar habilidades diferentes, mientras haya aporte Incorporación Escuchar y tomar en cuenta propuestas Honestidad Sobre lo que va bien y lo que va mal; sus conocimientos Selección n de personal Fuentes de información Los interesados Entrevistas: útiles en aspectos de comunicación y habilidades sociales; fallan en aspectos técnicos Recomendaciones de personas conocidas que han trabajado con los interesados
28 Selección n de personal Algunos factores que influyen: Experiencia en dominio de aplicación (algunos) Experiencia en plataforma (si hay programación de bajo nivel) Experiencia en lenguaje (en proyectos cortos) Habilidad para resolver problemas (difícil; por trabajos) Soporte educativo (poco relevante) Habilidad de comunicación (oral, escrita, idiomas) Adaptabilidad (según trabajos realizados) Actitud (positiva respecto al trabajo; deseo de aprender) Personalidad (compatibilidad) Selección n de personal Pasos para seleccionar Crear especificación del trabajo Crear perfil del empleado Conseguir solicitantes Examinar currícula Entrevistas Aptitudes Personalidad Muestras de trabajo Entrevista personal
29 Motivación Las personas se motivan por satisfacción de necesidades, en orden creciente (según Maslov): Fisiológicas (comer, dormir) Seguridad (entorno protector) Sociales (parte de grupo) Estima (sentirse respetado) Autorrealización (desarrollo personal) Enfocarse en éstas Motivación Sociales: Dar tiempo a conocerse, lugar de intercambio, mecanismos informales Estima: Mostrar que tienen valor, reconocer logros Autorrealización: Asignar tareas demandantes, pero no imposibles, programas de capacitación
30 Motivación Orientación de personas: A tareas: se motivan por su trabajo, reto intelectual, técnico (el software como reto) A sí mismos: su éxito y reconocimiento (software como medio) A interacción: presencia y acciones de compañeros; importantes en enfoque orientado a usuarios Puede ser variable, pero una domina Gestión n de grupos Factores para equipos Composición: balance de habilidades, experiencia y personalidades Cohesión: verdadero equipo, no colección de individuos Comunicación: que exista y sea efectiva Organización: todos se sienten valorados y satisfechos de su papel
31 Gestión n de equipos En cuanto a balance de personalidades: Los orientados a tareas son buenos para los aspectos técnicos; deben comprender conjunto, no aislarse. Unos ayudan a comunicar y los orientados a sí mismos son persistentes, seguirán hasta el final Gestión n de equipos Sobre cohesión Grupo más importante que individuos, metas de grupo, lealtad, protección Se forman estándares de calidad del grupo Depende de la cultura organizacional Problemas: resistencia irracional a cambio de liderazgo; pensamiento de grupo (no se piensa críticamente)
32 Gestión n de equipos Comunicación: Influye tamaño de grupo; al crecer crecen demasiado los canales de comunicación, distracción La estructura afecta: los grupos menos formales se comunican mejor La composición: personas parecidas chocan; balance de sexos El entorno afecta (área de trabajo, cierta privacidad) Personal El factor humano es tan importante que el SEI desarrollo el Modelo de Madurez de Gestión Capacidad Personal (MMCGP). Existen varias áreas clave prácticas para el personal de software: Reclutamiento Selección Gestión del desempeño Entrenamiento Retribución Desarrollo de carrera Diseño de organización y trabajo Desarrollo de cultura de equipo
33 Modelo de madurez de capacidades del personal PCMM A partir del modelo CMM se han desarrollado modelos específicos. Para el personal, siendo muy importante, se creó el PCMM Ahora se ha integrado en CMMI People Capacity Maturity Model Modelo de madurez de capacidad del personal
34 Antecedentes Las compañías globales y de alta tecnología requieren Buenos productos y servicios Desarrollar y retener empleados con talento y habilidades Se busca que no sólo sigan órdenes sino que sean centros inteligentes de acción hacia fines comunes Antecedentes Principios para atraer, desarrollar y retener personal valioso (J. Pfeffer, Stanford): Seguridad en el empleo Contratación selectiva Equipos autoadministrados y descentralización de toma de decisiones Compensación alta según rendimiento de la organización Entrenamiento Reducir barreras y distinciones de estatus Compartir información financiera y de rendimiento
35 Niveles del modelo Nivel 1: Inicial (Gestión inconsistente) Nivel 2: Gestionado (Gestión del personal) Prácticas repetibles Prácticas basadas en competencias Nivel 3: Definido (Gestión por competencias) Nivel 4: Predecible(Gestión de capacidades) Nivel 5: Optimizado (Gestión del cambio) Prácticas medibles Mejora continua de practicas Nivel 1 Inicial Se hace ad-hoc, se reinventa cada vez No hay manera confiable de estimar esfuerzo El resultado depende del personal Se dice que el personal es valioso Pero no se hace nada por mejorar su valor
36 Nivel 2 Gestionado La base para mejorar, que sea repetible Establecer procesos bien definidos Control de compromisos y líneas base No estar presionando y correteando al personal innecesariamente Nivel 3 Definido Se identifican las mejores prácticas Se documentan e integran a procesos Se definen métricas Se estandariza para toda la organización Surge cultura común
37 Nivel 4 Predecible Se administra a partir de datos que describen el rendimiento de la empresa; no solo hitos Se caracterizan estadísticamente los procesos críticos Al volverse predecibles y cuantitativos, se adquiere conocimiento que permite mejorar las prácticas Nivel 5 Optimizado Del conocimiento que se tiene se van proponiendo acciones de mejoramiento: Ajustar procesos Usar nuevas tecnologías Se administra el cambio Se identifican defectos persistentes
38 Resumen Se crea un ambiente donde Las prácticas son repetibles Las mejores prácticas se transfieren entre grupos Se reducen las variaciones en rendimiento Las prácticas se mejoran de continuo Problemas en organizaciones inmaduras Sobrecarga de trabajo Ambiente de distracción Metas de rendimiento y retroalimentación poco claras Carencia de conocimiento relevante y habilidad Mala comunicación Baja moral
39 Áreas de proceso Arquitectura
40 PROCESO -2- Proceso Un proceso dice quién está haciendo qué y cuándo y cómo lograr la meta Booch, Jacobson, Rumbaugh
41 Proceso Un proceso de software proporciona el marco de trabajo para establecer el plan detallado para el desarrollo del software Dos tipos de actividades son generales en cualquier proceso: Establecer: tareas, hitos, productos de trabajo y puntos de control de calidad Controlar la calidad, gestionar la configuración de software y medir resultados. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1 Actividades Un proceso tiene actividades genéricas para cualquier proyecto Se detallan según necesidades de cada proyecto También tiene actividades sombrilla o de protección
42 Actividades genéricas Comunicación (requerimientos) Planeación Modelado (análisis, diseño) Construcción (codificación y prueba) Despliegue Actividades sombrilla Gestión del riesgo Seguimiento y control Revisiones Medición Gestión de la configuración Gestión de reutilización Preparación y producción de productos del trabajo
43 Procesos Personal Software Process proyectos pequeños de una persona Team Software Process proyectos para equipos pequeños Modelos reconocidos generales: cascada, espiral, iterativos Modelos con nombre propio: Proceso Unificado, Ciclo de vida estructurado de Yourdon Métodos Ágiles Scrum, Crystal Clear, XP Proyectos según Proceso Unificado 86
44 Selección n de proceso En cada proyecto se selecciona un proceso, entre los anteriores u otros o se forma específico para un proyecto Descomposición n del proceso Una vez escogido el proceso: Ejemplos: Lineal secuencial, para sistemas muy pequeños y muy bien definidos DRA, para restricciones de tiempo ceñido y se puede modularizar Incremental, si no puede entregarse el producto completo por restricciones de tiempo o falta de claridad en los requerimientos Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill
45 Descomposición n del proceso (1/2) Para proyectos pequeños en menos de 48 horas se debe: Desarrollar una lista de conflictos que deben clarificarse. Reunirse con los clientes para abordar los conflictos que deben clarificarse. Desarrollar en conjunto un enunciado del ámbito. Revisar el enunciado del ámbito con todos los implicados. Modificar el enunciado del ámbito según se requiera. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill Descomposición n del proceso (2/2) Para proyecto más complejo, actividad de comunicación; las actividades serían: 1. Revisar la petición del cliente. 2. Planificar y programar una reunión formal con el cliente. 3. Llevar a cabo investigaciones para especificar la solución propuesta y los enfoques existentes. 4. Preparar un "documento de trabajo" y una agenda para la reunión formal. 5. Celebrar la reunión. 6. Desarrollar en conjunto miniprospectos que reflejen los datos, función y características de comportamiento del software. 7. Revisar cada miniprospecto o para valorar su corrección, consistencia y eliminar la ambigüedad. 8. Ensamblar los miniprospectos en un documento más amplio. 9. Revisar el documento más amplio o colección de casos de uso con todos los implicados. 10.Modificar el documento más amplio según se requiera. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill7
46 Producto -3- Producto Antes de crear un proyecto se deben establecer: Objetivos y ámbito del producto Soluciones alternativas Identificación de restricciones técnicas y de gestión El desarrollador de software y cliente deben reunirse para definir objetivos y ámbito del producto En ese momento empieza la Ingeniería de procesos del negocio y continua con Ingeniería de Requerimientos. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill, Sección 21.1
47 Producto Para empezar un proyecto se necesitan estimaciones cuantitativas y un plan organizado. Para obtener lo anterior se necesita información sólida del producto a construir. Un análisis de requerimientos sería lo deseable, pero: Éste se lleva semanas y hasta meses Aunque se agilice, los requerimientos siempre cambian durante el proyecto. Dada la problemática se opta por establecer y acotar el ámbito del producto. Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill Ámbito de software (1/3) El ámbito se define al responder las siguientes preguntas: Contexto: Cómo encaja el software que se desarrollará en un sistema más grande, producto o contexto de negocio? Qué restricciones se imponen como resultado del contexto? Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill
48 Ámbito de software (2/3) Objetos de información: Qué objetos de datos visibles al usuario se producen como resultado del software? Qué objetos de datos se requieren de entrada? Función y desempeño Qué funciones realizará el software para transformar los datos de entrada? Habrá características de desempeño especial a considerar? Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill Ámbito de software (3/3) Características del ámbito del software No debe ser ambiguo ni incompresible a niveles de gestión y técnico Los enunciados deben acotarse, es decir, debe llevar datos cuantitativos. Ejemplos: Número de usuarios simultáneos, tamaño de la lista de correos, tiempo de respuesta máximo permitido. Contener las restricciones o limitaciones. Ejemplos: El costo del producto restringe el tamaño de la memoria Se describen los factores para reducir riesgos. Ejemplo: Los algoritmos deseados se comprenden bien y están disponibles en C++ Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill
49 Descomposición n del problema Se aplica en dos áreas: La funcionalidad a entregar El proceso a aplicar para entregar Para entender el problema se aplica la descomposición del mismo. Antes de comenzar la estimación se evalúa y refina la redacción del ámbito Generalmente basados en la funcionalidad Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill Ejemplo de refinamiento del ámbito (1/2) Construcción de un nuevo procesador de texto con lo que habitualmente se tiene y varias funciones novedosas: entrada continua mediante voz, edición automática de copia, capacidad de diseño de página, índice y contenido automáticos. El administrador del proyecto incluirá la lista de funciones y luego agregará preguntas respecto de a las funcionalidades novedosas.
50 Ejemplo de refinamiento del ámbito (2/2) Preguntas de refinamiento realizadas por el administrador del proyecto la entrada continua de voz requiere que el usuario del producto lo entrene? qué capacidades proporcionará la característica de edición de copia? cuán sofisticada será la capacidad de diseño de página? Conforme surjan las preguntas irán apareciendo las particiones Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill Selección n de Proceso Características importantes que hay que considerar para escoger el proceso Los clientes solicitaron el producto y el personal Las características del producto El ambiente de trabajo en que trabaja el equipo de software Una vez seleccionado el proceso se define el plan preliminar del proyecto con base en las actividades del marco de trabajo Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill
51 Combinación n de producto y proceso Una vez definido el marco de trabajo se deberá aplicar a cada una de las funciones establecidas para el producto (figura). Además deben incluirse las actividades de ingeniería para cada actividad del marco de trabajo El trabajo del AP consiste en estimar: Requisitos de recursos para cada celda de la matriz Fecha de inicio y final Productos de trabajo de cada tarea Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill Combinación n de producto y proceso ACTIVIDADES COMUNES DEL MARCO DEL TRABAJO DEL PROCESO Tareas de ingeniería de software Funciones del producto Entrada de texto Edición y formateo Edición automática de copia Capacidad de plantilla de página Índice y tabla de contenido automático Gestión de archivos Producción de documento Comunicación Planificación Modelado Construcción Despliegue Actividades del marco de trabajo Función principal del producto celda Pressman, R., Ingeniería de Software, 6ª ed., McGraw-Hill
52 Proyecto -4- Elementos importantes de un proyecto Hay tres procesos sucesivos que dan inicio a un proyecto: 1. Estudio de Factibilidad. Investigación que se realiza para decidir las perspectivas de un proyecto y si conviene empezarlo. 2. Planeación. Debe escribirse un plan que abarque todos las etapas en general y detalle la primera etapa, dejando las últimas etapas pendientes para cuando se tenga más información 3. Ejecución del proyecto. Donde se realizan las diversas etapas del ciclo de vida de un proyecto de software. Hughes, B. y Cotterell, M., Software Project Management, McGraw-Hill, Secciones 1.4
CMMI (Capability Maturity Model Integrated)
CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla
Más detallesMetodología básica de gestión de proyectos. Octubre de 2003
Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecución
Más detallesIntroducción a la Gestión y Dirección de Proyectos de Software
Introducción a la Gestión y Dirección de Proyectos de Software Nilda M. Pérez Otero Sistemas de Información II Cursada 2011 Facultad de Ingeniería - UNJu Fuentes: Ingeniería del Software. Un Enfoque Práctico
Más detallesCurso. Introducción a la Administracion de Proyectos
Curso Introducción a la Administracion de Proyectos Tema 5 Procesos del área de Integración INICIAR PLANEAR EJECUTAR CONTROL CERRAR Desarrollar el Acta de Proyecto Desarrollar el Plan de Proyecto Dirigir
Más detallesCMM - Capability Maturity Model. Estructura de CMM... Componentes de CMM. Estructura de CMM
CMM - Capability Maturity Model Estructura de CMM... Es un marco que describe los elementos claves de un proceso de software efectivo. Describe un camino de mejora evolutivo desde un proceso ad hoc inmaduro
Más detallesGestión de Configuración del Software
Gestión de Configuración del Software Facultad de Informática, ciencias de la Comunicación y Técnicas Especiales Herramientas y Procesos de Software Gestión de Configuración de SW Cuando se construye software
Más detallesGestión y Desarrollo de Requisitos en Proyectos Software
Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería
Más detallesSW-CMM Capability Maturity Model for Software
SW-CMM Capability Maturity Model for Software Introducción 1986 Comienzan Estudios. SEI (Software Engineering Institute - UCM). 1991 Nace CMM v1.0 1994 CMM v1.1 P-CMM SE-CMM SW-CMM CMMs IPD-CMM CMMI SA-CMM
Más detallesEL PROCESO DE BENCHMARKING
EL PROCESO DE BENCHMARKING Michael J. Spendolini El benchmarking es un proceso sistemático y continuo para evaluar los productos, servicios y procesos de trabajo de las organizaciones que son reconocidas
Más detallesPlaneación del Proyecto de Software:
Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los
Más detalles3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE
3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar
Más detallesCiclo de vida y Metodologías para el desarrollo de SW Definición de la metodología
Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto
Más detallesLa evaluación del desempeño del personal es un punto muy delicado, ya que debe ser objetiva y justa para no generar conflictos
Evaluación del desempeño y competencias Jack Fleitman La evaluación del desempeño del personal es un punto muy delicado, ya que debe ser objetiva y justa para no generar conflictos Para que exista un sistema
Más detallesDE VIDA PARA EL DESARROLLO DE SISTEMAS
MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS 1. METODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS. El desarrollo de Sistemas, un proceso
Más detallesGERENCIA DE INTEGRACIÓN
GERENCIA DE INTEGRACIÓN CONTENIDO Desarrollo del plan Ejecución del plan Control de cambios INTRODUCCIÓN La gerencia de integración del proyecto incluye los procesos requeridos para asegurar que los diversos
Más detallesProceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:
PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo
Más detallesPrácticas ITIL para un mejor flujo de trabajo en el helpdesk
Prácticas ITIL para un mejor flujo de trabajo en el helpdesk Se diferencia tres partes de gestión para mejorar la resolución de las incidencias de soporte técnico según el marco ITIL: 1. Gestión de Incidencias
Más detallesCalidad de Software - CMM
Calidad de Software - CMM Herramientas y Procesos de Software Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales Lic. Cecilia Palazzolo Año 2008 1 Qué es un modelo de procesos?
Más detallesTECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC CALIDAD DE SOFTWARE Guía para Examen Segundo Parcial Grupo 6501
1. Qué incluye la ingeniería del software con SQA? Entrenamiento, soporte al consumidor instalación. 2. Menciona algunas características del software: Elemento lógico. Desarrollado no fabricado. No se
Más detallesFundamentos del diseño 3ª edición (2002)
Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software
Más detallesProcesos Críticos en el Desarrollo de Software
Metodología Procesos Críticos en el Desarrollo de Software Pablo Straub AgileShift Imagine una organización de desarrollo de software que consistentemente cumple los compromisos con sus clientes. Imagine
Más detalles4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review)
1_Visión general de SCRUM 2_Teoría de Scrum 3_El Equipo Scrum (Scrum Team) 3.1_El Dueño de Producto (Product Owner) 3.2_El Equipo de Desarrollo (Development Team) 3.3_El Scrum Master 4_Eventos de Scrum
Más detallesResumen General del Manual de Organización y Funciones
Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de
Más detallesFigure 7-1: Phase A: Architecture Vision
Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como
Más detallesQué es el Modelo CMMI?
El principal problema que tienen las empresas en sus áreas de tecnología, así como las empresas desarrolladoras de software al iniciar un proyecto, radica en que el tiempo de vida del proyecto y el presupuesto
Más detallesAUDITORÍA ADMINISTRATIVA INFORME. 1. Brindar a la organización los elementos necesarios para mejorar su funcionamiento.
Naturaleza AUDITORÍA ADMINISTRATIVA INFORME Auditoria Administrativa Alcance Toda la empresa Antecedentes No existen Objetivos 1. Brindar a la organización los elementos necesarios para mejorar su funcionamiento.
Más detallesVICERRECTORÍA DE ADMINISTRACIÓN Y ASUNTOS ECONÓMICOS DIRECCIÓN DE DESARROLLO DE PERSONAS. Estructura de Cargos y Competencias Institucionales
VICERRECTORÍA DE ADMINISTRACIÓN Y ASUNTOS ECONÓMICOS DIRECCIÓN DE DESARROLLO DE PERSONAS Estructura de Cargos y Competencias Institucionales Campus San Juan Pablo II Presentación La Universidad Católica
Más detallesCICLO DE VIDA DEL SOFTWARE
CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en
Más detallesCAPÍTULO 4. FORMA DE EVALUACIÓN CMM. 4.1 Evolución de los métodos de valoración del SEI
CAPÍTULO 4. FORMA DE EVALUACIÓN CMM Tanto para el programa ALTA como para este trabajo de tesis, es importante conocer no sólo el modelo de Capacidad de Madurez, sino la forma en que se evalúa el nivel
Más detallesPlan de Administración del Proyecto
L México 2002 Atención Ciudadana y Gestión de Programas Sociales Plan de Administración del Proyecto Introducción: El Plan de Administración del Proyecto provee información de cómo el proyecto debe ser
Más detallesEl objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos.
Gestión de proyectos Duración: 45 horas Objetivos: El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos. Contenidos:
Más detallesGestión de proyectos
Gestión de proyectos Horas: 45 El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos. Gestión de proyectos El
Más detallesEl Gerente de Proyecto. 3: El Gerente de Proyecto. Analogía - Responsabilidades. Liderazgo del Proyecto. Responsabilidades Implícitas
3: El Gerente de Proyecto El Gerente de Proyecto Selección del Gerente de Proyecto Habilidades Requeridas Criterios aplicables a la Selección. Descripción de Tareas. Project Charter 1 2 Responsabilidades
Más detallesGUÍA ESENCIAL DE LAS HABILIDADES ESENCIALES
LA GUÍA ESENCIAL DE LAS ESENCIALES DE INTERACCIÓN CÓMO HACER QUE SUS LÍDERES REGRESEN A LO BÁSICO Y DESARROLLEN LAS ESENCIALES QUE MÁS NECESITAN. A pesar de la mayor complejidad, mayores exigencias y el
Más detallesActividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.
Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas
Más detallesIs not jus power, is reliability and trust. Yei Systems S.A. de C.V.
Is not jus power, is reliability and trust Yei Systems S.A. de C.V. Nos es muy grato dirigirnos a Usted para ofrecerle nuestros servicios de Auditoría de sistemas, Desarrollo de software y Seguridad Informática
Más detallesI N T E R P R E T A T I V O
S E L E C C I Ó N D E S A R R O L L O L I D E R A Z G O H O G A N D E S A R R O L L O I N T E R P R E T A T I V O INVENTARIO DE RAZONAMIENTO DE NEGOCIOS DE HOGAN Reporte Para: High Score Usuario: UH007438
Más detallesResumen del Contenido del Examen PMP
Resumen del Contenido del Examen PMP Tareas Dominio I Inicio del Proyecto - 13 % Realizar una valoración del proyecto basada en la información disponible, mediante reuniones con el patrocinador, el cliente,
Más detallesMetodologías Ágiles Desde una Perspectiva de Project Management. Fernando Contreras Velásquez Project Management & Engineering Services.
Metodologías Ágiles Desde una Perspectiva de Project Management Fernando Contreras Velásquez Project Management & Engineering Services. Ing. Fernando Contreras Velásquez: PMP, PMI-SP, PMI-RMP Acerca del
Más detallesDiseño orientado al flujo de datos
Diseño orientado al flujo de datos Recordemos que el diseño es una actividad que consta de una serie de pasos, en los que partiendo de la especificación del sistema (de los propios requerimientos), obtenemos
Más detalles10 PRÁCTICAS BASALES DE LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CUBA
10 PRÁCTICAS BASALES DE LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CUBA Visión desde el Modelo de Calidad para el Desarrollo de Aplicaciones Informáticas AUTORES MsC. Anisbert Suárez Batista Ing. Maikel Muñoz
Más detallesEl proceso unificado en pocas palabras
El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,
Más detallesADMINISTRACIÓN DE PROYECTOS
QUITO INGENIERIA MECANICA ADMINISTRACIÓN DE PROYECTOS JUAN MARCELO IBUJES VILLACÍS ADMINISTRACIÓN DE PROYECTOS Contenido tomado de referencia de la Guía de los Fundamentos para la Dirección de Proyectos
Más detallesEMPRESAS PÚBLICAS DE MEDELLÍN E.S.P. DIRECCIÓN CONTROL INTERNO PROYECTO NORMALIZACIÓN ACTIVIDAD DE AUDITORÍA INTERNA
DCI-PN-EA-01 VERSIÓN 02 Página 2 de 12 TABLA DE CONTENIDO 1. INTRODUCCIÓN... 3 2. ROL... 3 3. PROFESIONALIDAD... 3 4. AUTORIDAD... 4 5. ORGANIZACIÓN... 4 6. INDEPENDENCIA Y OBJETIVIDAD... 5 7. ALCANCE...
Más detallesCAPITULO V. Conclusiones y recomendaciones. Este capítulo tiene como objetivo mostrar las conclusiones más significativas que se
CAPÍTULO V 74 CAPITULO V Conclusiones y recomendaciones Este capítulo tiene como objetivo mostrar las conclusiones más significativas que se identificaron a lo largo de la investigación. Asimismo, se presentan
Más detallesFÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe
FÁBRICA DE SOFTWARE Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe FÁBRICA DE AUTOS Entrada Salida Autos FÁBRICA DE SOFTWARE Entrada Salida Información
Más detallesCOMO REALIZAR UN DIAGNÓSTICO INICIAL Y DEFINIR LA POLITICA DE SEGURIDAD PARA EL SISTEMA DE GESTIÓN EN CONTROL Y SEGURIDAD BASC
COMO REALIZAR UN DIAGNÓSTICO INICIAL Y DEFINIR LA POLITICA DE SEGURIDAD PARA EL SISTEMA DE GESTIÓN EN CONTROL Y SEGURIDAD BASC AL FINALIZAR EL CURSO.. Estaremos en capacidad de: Conocer la metodología
Más detallesINTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION
INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION. Los sistemas que el analista diseña día a día, la tecnología, las personas, que utilizan el
Más detallesISO 9001:2015 Comprender los cambios clave. Lorri Hunt
ISO 9001:2015 Comprender los cambios clave Lorri Hunt Exención de responsabilidad Si bien la información suministrada en esta presentación pretende explicar con precisión la actualización de la ISO 9001,
Más detallesCAPITULO VI PLAN DE IMPLEMENTACIÓN DEL SISTEMA DE PRESUPUESTOS DE COSTOS DE TIEMPOS ESTÁNDARES DE CONFECCIÓN DE PRENDAS DE VESTIR DE TEJIDO DE PUNTO.
204 CAPITULO VI PLAN DE IMPLEMENTACIÓN DEL SISTEMA DE PRESUPUESTOS DE COSTOS DE TIEMPOS ESTÁNDARES DE CONFECCIÓN DE PRENDAS DE VESTIR DE TEJIDO DE PUNTO. 6.1 INTRODUCCIÓN El éxito de la aplicación del
Más detallesMejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos
ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados
Más detallesElementos requeridos para crearlos (ejemplo: el compilador)
Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción
Más detallesModelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software
Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software Hugo F. Arboleda Jiménez. MSc. Docente-Investigador, Facultad de Ingenierías, Universidad de San
Más detallesITIL FOUNDATION V3 2011
ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la
Más detallesCapítulo 16. Ventas personales y promoción de ventas
Capítulo 16 Ventas personales y promoción de ventas 16-1 Objetivos de aprendizaje Presentación del capítulo Ventas personales Administración de la fuerza de ventas El proceso de las ventas personales Promoción
Más detallesGESTION OPERATIVA. Niveles de gestión
GESTION OPERATIVA La gestión deja de ser una tarea aislada para constituirse en una herramienta que sirve para ejecutar las acciones necesarias que permitan ordenar, disponer y organizar los recursos de
Más detalles0. Introducción. 0.1. Antecedentes
ISO 14001:2015 0. Introducción 0.1. Antecedentes Conseguir el equilibrio entre el medio ambiente, la sociedad y la economía está considerado como algo esencial para satisfacer las necesidades del presente
Más detallesPor qué fracasan los Proyectos?
Por qué fracasan los Proyectos? Ing. Bernardo García Consultor en Gerencia de Proyectos Qué es exactamente un proyecto bien hecho EXITOSO? Pensará que es relativamente sencillo describir las claves de
Más detallesCALIDAD TOTAL. Visión estratégica y buena gestión son los ingredientes fundamentales.
CALIDAD TOTAL Visión estratégica y buena gestión son los ingredientes fundamentales. ALFREDO SERPELL Ingeniero civil industrial UC Phd University of Texas at Austin.Profesor titular ingeniería y gestión
Más detallesLos profesores Flipantes
Los profesores Flipantes 1 0. Índice 1. Introducción al TSP 2. La lógica del TSP 3. Lanzamiento de un Proyecto TSP. 4. Fases del Ciclo TSPi. 5. TSPi en DSIC. 2 1. Introducción al TSP. El software suele
Más detallesPlanificación, Gestión y Desarrollo de Proyectos
Planificación, Gestión y Desarrollo de Proyectos Conceptos básicos Planificación de un proyecto Gestión de un proyecto Desarrollo de un proyecto 1 Conceptos básicos: Proyecto Conjunto de actividades que
Más detallesMETODOLOGÍA PARA LA MEJORA Y DIGITALIZACIÓN DE TRÁMITES. Etapa 1: Diagnóstico Cómo es mi proceso actual?
METODOLOGÍA PARA LA MEJORA Y DIGITALIZACIÓN DE TRÁMITES Etapa 1: Diagnóstico Cómo es mi proceso actual? El primer paso para mejorar un trámite, ya sea con miras a digitalizarlo o solo para mejorarlo en
Más detallesÁrea Académica: Licenciatura Sistemas Computacionales. Profesor: Lic. Virginia Arguelles Pascual
Área Académica: Licenciatura Sistemas Computacionales Materia: Gestión de Proyectos Profesor: Lic. Virginia Arguelles Pascual Periodo: Julio-Diciembre Tema: El proceso de software y métricas del proyecto.
Más detallesIntroducción. Definición de los presupuestos
P o r q u é e l p r e s u p u e s t o d e b e s e r e l c a m i n o a s e g u i r p a r a g a r a n t i z a r e l é x i t o d e s u e m p r e s a? Luis Muñiz Economista Introducción El aumento de la incertidumbre
Más detallesCURSO COORDINADOR INNOVADOR
CURSO COORDINADOR INNOVADOR PRESENTACIÓN La tarea que el Ministerio de Educación se propone a través de Enlaces, en relación al aseguramiento del adecuado uso de los recursos, con el fin de lograr un impacto
Más detallesTrabajo lean (1): A que podemos llamar trabajo lean?
Trabajo lean (1): A que podemos llamar trabajo lean? Jordi Olivella Nadal Director de Comunicación del Instituto Lean Management Este escrito inicia una serie de artículos sobre la organización en trabajo
Más detalles3. Procedimiento administrativo para la realización de auditorías a sistemas de medición de la calidad del aire.
3. Procedimiento administrativo para la realización de auditorías a sistemas de medición de la calidad del aire. 3.1 Descripción general de los pasos de la auditoría. Las auditorías comprenderán tres etapas
Más detallesSinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1
Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1 Conceptos básicos Qué es un portafolio? Es una colección de proyectos, programas y otras actividades
Más detallesADMINISTRACIÓN DE PROYECTOS. Ing. Juan M. Ibujés Villacís, MBA
ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS Contenido tomado de referencia de la Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK ) Cuarta edición Juan M. Ibujés Villacís
Más detallesBloque I: Conceptos básicos y fundamentos de la Dirección de Proyectos.
1.- Objeto. Presentar y fomentar la existencia de metodologías en Dirección de Proyectos o Project Management a través de experiencias, documentos, normas y estándares nacionales e internacionales. Ofrecer
Más detallesGestión de la Configuración
Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de
Más detallesGUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000
1 INTRODUCCIÓN Dos de los objetivos más importantes en la revisión de la serie de normas ISO 9000 han sido: desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas
Más detallesPRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE
PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,
Más detallesLISTA DE COMPROBACIÓN DE RIESGOS EN PROYECTOS SOFTWARE. Esta lista agrupa los riesgos de proyectos software en las siguientes categorías:
LISTA DE COMPROBACIÓN DE RIESGOS EN PROYECTOS SOFTWARE Esta lista agrupa los riesgos de proyectos software en las siguientes categorías: A. Elaboración de la Planificación B. Organización y Gestión C.
Más detallesPlan de estudios ISTQB: Nivel Fundamentos
Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE
Más detallesCAPITULO VI ESTRATEGIAS DE OUTSOURCING
CAPITULO VI ESTRATEGIAS DE OUTSOURCING Cuando una compañía decide llevar a cabo un proceso de outsourcing debe definir una estrategia que guíe todo el proceso. Hay dos tipos genéricos de estrategia de
Más detallesDESARROLLO AGIL ING. MA. MARGARITA LABASTIDA ROLDÁN
DESARROLLO AGIL ING. MA. MARGARITA LABASTIDA ROLDÁN CONTENIDO Qué es un proceso agil Proceso Ágil Otros modelos ágiles de proceso Programación extrema Desarrollo adaptativo de software Método de desarrollo
Más detallesMetodologías de Desarrollo de Sistemas de Información
Metodologías de Desarrollo de Sistemas de Información Metodología para el Desarrollo de SI Las metodologías son sistemas completos de técnicas que incluyen procedimientos paso a paso, productos resultante,
Más detallesGUIA DE TRABAJO APLICATIVO
GUIA DE TRABAJO APLICATIVO 169 170 Supervisión, Monitoreo y Evaluación ÍNDICE INTRODUCCIÓN 173 UNIDAD I LA EVALUACIÓN DEL PLAN OPERATIVO 175 ACTIVIDAD Nº l: Definiendo los resultados, procesos e insumos
Más detallesREPORTE REGIONAL ARGENTINA Tendencias en Argentina Tercerización del Project Management Por: Ana María Rodríguez, Corresponsal Internacional PMWT
REPORTE REGIONAL ARGENTINA Tendencias en Argentina Tercerización del Project Management Por: Ana María Rodríguez, Corresponsal Internacional PMWT Siguiendo el crecimiento de la economía en Argentina, el
Más detallesGestión de Proyectos de desarrollo de software. Ing. Rafael Bentancur Universidad ORT Uruguay
Gestión de Proyectos de desarrollo de software Ing. Rafael Bentancur Universidad ORT Uruguay Algunas definiciones Proyecto: emprendimiento temporario que debe crear un producto o servicio único (PMBOK)
Más detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer
Más detallesSeguimiento y evaluación
Seguimiento y evaluación Por qué es necesario contar con herramientas para el seguimiento y la evaluación? Es la manera en que se puede evaluar la calidad e impacto del trabajo en relación con el plan
Más detallesISO 9000 Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007
ISO 9000 ISO ISO: International Standards Organization. ISO 9000: Normas que enuncian exigencias en materia del manejo y de la garantía de la calidad en una organización. La Norma ISO 9000 NO especifica
Más detalleswww.fundibeq.org Además, se recomienda su uso como herramienta de trabajo dentro de las actividades habituales de gestión.
DIAGRAMA DE RELACIONES 1.- INTRODUCCIÓN Este documento describe los pasos del proceso de construcción e interpretación de una de las herramientas más potentes para el análisis de problemas y situaciones
Más detallesSede Escazú, Plaza Tempo 4031-0999 40310991 E-mail: cit@ulacit.ac.cr
16-0079 / 29-0952 FORMULACIÓN PROYECTOS Descripción General: Provee una introducción que abarca el ciclo de vida completo del desarrollo de un proyecto, desde que se concibe en los niveles más altos de
Más detallesPlanificación de Sistemas de Información
Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación
Más detallesPLANIFICACIÓN ESTRATÉGICA: CONCEPTO Y ASPECTOS BÁSICOS.
PLANIFICACIÓN ESTRATÉGICA: CONCEPTO Y ASPECTOS BÁSICOS. QUÉ ES LA PLANIFICACIÓN? Planificar no es adivinar el futuro, sino más bien, es tomar un conjunto de decisiones que llevadas a la práctica a través
Más detallesPlanificación de Sistemas de Información
Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación
Más detalles2. PROCESO DE LA CAPACITACIÓN
2. PROCESO DE LA CAPACITACIÓN Debido a que la meta primaria de la capacitación es contribuir a las metas globales de la organización, es preciso desarrollar programas que no pierdan de vista las metas
Más detallesCapítulo 2. Metodologías de selección de personal
Capítulo 2. Metodologías de selección de personal 2.1 Introducción La selección de personal es una actividad en la cual toda empresa invierte parte de sus recursos, debido a que es una tarea de vital importancia.
Más detallesSesión No. 12. Contextualización: Nombre de la sesión: SAP segunda parte PAQUETERÍA CONTABLE
Paquetería contable PAQUETERÍA CONTABLE Sesión No. 12 Nombre de la sesión: SAP segunda parte Contextualización: Los sistemas ERP son actualmente las herramientas que se han impuesto y son la base operativa
Más detallesEl dinamizador como referente Seminario de Formación febrero de 2004 Contenidos 1. Perfil de la persona dinamizadora 2. Papel de la persona dinamizadora 3. Funciones y tareas 4. El Centro y su entorno
Más detallesUniversidad Autónoma de los Andes Evaluación y Auditoría Informática Unidad 1: Metodología de una Auditoría de Sistemas Computacionales - ASC Ing. John Toasa Espinoza http://waudinfingjohntoasa.wikispaces.com
Más detallesAUDITORÍAS Y AUDITORES ISO 9000:2000
AUDITORÍAS Y AUDITORES ISO 9000:2000 Ing. Miguel García Altamirano Servicios CONDUMEX S.A. de C.V. Delegado Mexicano en el Comité Internacional ISO TC 176 en el grupo JWG "Auditorías" Resumen: Los sistemas
Más detallesGerencia de Proyectos, un enfoque. Marco de referencia
Gerencia de Proyectos, un enfoque Directivo Marco de referencia Confidencialidad Este documento está dirigido a las personas que participan en este seminarioynopuedeserreproducidoocopiadodemaneraalguna,entodoo
Más detallesGuía de Planificación Estratégica de la Informática Educativa
Cierre de Brecha Digital Guía de Planificación Estratégica de la Informática Educativa Dirigida al Sostenedor y al Establecimiento Educacional Estimado Sostenedor y Director, El Ministerio de Educación
Más detallesTérminos definiciones
Términos y definiciones 3Claves para la ISO 9001-2015 Términos y definiciones: ISO9001 utiliza una serie de definiciones ligadas a la gestión de la calidad, que también deben ser comprendidas por la organización
Más detallesAdministración de proyectos. Organizar, planificar y programar los proyectos de software
Administración de proyectos Organizar, planificar y programar los proyectos de software Administración de proyectos Trata de las actividades que hay que realizar para asegurar que el software se entregará
Más detallesCAPITULO 2 - POR QUÉ NECESITAN LAS EMPRESAS UN CUADRO DE MANDO INTEGRAL?
CAPITULO 2 - POR QUÉ NECESITAN LAS EMPRESAS UN CUADRO DE MANDO INTEGRAL? Los indicadores financieros. Desde hace mucho tiempo se utiliza el sistema de mediciones financiero, desde la época de los egipcios
Más detalles