• Save
Contratación De Software V3   Hernán Ortiz PMP
Upcoming SlideShare
Loading in...5
×
 

Contratación De Software V3 Hernán Ortiz PMP

on

  • 1,950 views

Recomendaciones para contratar software

Recomendaciones para contratar software

Statistics

Views

Total Views
1,950
Views on SlideShare
1,947
Embed Views
3

Actions

Likes
1
Downloads
0
Comments
1

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Permitir las descargas potencializa la difusión y adquisición del conocimiento
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Contratación De Software V3   Hernán Ortiz PMP Contratación De Software V3 Hernán Ortiz PMP Document Transcript

    • 22/08/2010Diplomado en Gerencia de Sistemas y TecnologíaContratación de SoftwareProfesor: Ing. Hernan Ortiz A., MBA, PMPAgo-10 Objetivo del Programa Al finalizar el curso, los estudiantes podrán identificar los aspectos fundamentales del proceso de contratación para proyectos de software Metodología El curso se desarrollara acorde al contenido programático presentado a continuación, un taller práctico y espacios de discusión en el aula de clase 1
    • 22/08/2010BibliografiaEl curso se desarrolla bajo lineamientos de las mejores prácticas delProject Management Institute y del Software Engineering Institute(Carnegie Mellon University)1. PMBOK A guide to the project management body of knowledge, 4ª Edition2. CMMI for development V1.2Contenido Programa1. Alineamiento estratégico <2. Gestión del proyecto de software3. Levantamiento de requerimientos4. Análisis de riesgos en contratación5. Proceso de Administración de Contratos6. Aceptación de productos y servicios7. Cierre y Lecciones Aprendidas 2
    • 22/08/2010 Alineamiento Estratégico Alineamiento Estratégico • Identificación: crear una lista actualizada de proyectos que serán administrados a través del portafolio • Categorización: clasificar los proyectos en grupos de negocios sobre los cuales existen características comunes. Estas categorías se definen con base en el plan estratégico • Evaluación: colectar toda la información cualitativa y cuantitativa necesaria para evaluar y facilitar el proceso de selección • Selección: elaboración de una lista corta de componentes tomando como base las recomendaciones del proceso de evaluación y los criterios definidos por la organizaciónPágina - 6 - Material preparado por Hernan Ortiz A. MBA, PMP 3
    • 22/08/2010 Alineamiento Estratégico • Priorización: ordenar los componentes en su categoría estratégica, en marco de tiempo y perfil de riesgo. • Balancear: desarrollar una mezcla con el mayor potencial para soportar los objetivos estratégicos • Autorizar: formalmente asignar recursos financieros y humanos requeridos para desarrollar el caso de negocio o ejecutar la iniciativa • Revisión: colectar indicadores de desempeño, hacer reportes de seguimiento y revisar el portafolio con una frecuencia pre- establecida para asegurar alineamiento estratégico y una efectiva utilización de los recursos.Página - 7 - Material preparado por Hernan Ortiz A. MBA, PMP En un ciclo de negocios típico los componentes del portafolio de proyectos de tecnología serán revisados y validados en relación a: Alineamiento estratégico Viabilidad basado en resultados Valor y relación con otros componentes Disponibilidad de recursos Prioridad en el portafolio 4
    • 22/08/2010 Alineamiento Estratégico Proyecto Proyecto Cambiar Proyecto La Entregar Proyecto los Operación Beneficios Operación del Negociola Define Propone Estrategia cambios con beneficiosPágina - 9 - Material preparado por Hernan Ortiz A. MBA, PMP Alineamiento Estratégico • Cuales son los factores determinantes para que un proyecto de software este alineado estratégicamente? Ejercicio 1: • Utilizando el diagrama de Ishikawa, establezca las causas de no alineamiento de los proyectos de software • Establezca acciones que faciliten el proceso de alineamiento para su organización. • Haga las recomendaciones pertinentes. EJ 1Página - 10 - Material preparado por Hernan Ortiz A. MBA, PMP 5
    • 22/08/2010 Diagrama de Ishikawa Medidas Herramientas Insumos /Información No alineamiento de Proyectos de software Recurso Medio Metodologías Humano AmbientePágina - 11 - Material preparado por Hernan Ortiz A. MBA, PMP Contenido Programa 1. Alineamiento estratégico 2. Gestión del proyecto de software< 3. Levantamiento de requerimientos 4. Análisis de riesgos en contratación 5. Proceso de Administración de Contratos 6. Aceptación de productos y servicios 7. Cierre y Lecciones Aprendidas 6
    • 22/08/2010 SOW Caso de Negocios Contrato “Sponsor “ o patrocinador Grupo de proceso de inicio Registro de Activos de los Interesados procesos Estrategia de Carta del proyecto Factores manejo de “Charter” ambientales de la interesados organización Plan de Gerencia Grupo de del Proyecto procesos de Planeación Organización de la empresa Grupo de Procesos Monitoreo y Control Acuerdos Documentos Del Requisitos Proyecto Cliente Decisiones de compra Criterios de selección Producto Final, Resultados Grupo de procesos de Ejecución Ofertas Cambios aprobados Medidas de calidad Contrato de Reportes de compra desempeño Vendedores Entregables Solicitud de cambios Información de * Tomado del PMBOK trabajo Vendedores Guide – Fourth Edition seleccionados Grupo de Entregables aceptados procesos de Cierre Documentación de compras Gestión de Proyectos de Software Definiciones importantes • Proyecto • Gestión de Proyecto • Ciclo de Vida del Proyecto • Interesados – Actores Claves • Restricciones del Proyecto • Requerimientos • EntregablesPágina - 14 - Material preparado por Hernan Ortiz A. MBA, PMP 7
    • 22/08/2010 Que es un proyecto ? Un proyecto tiene un objetivo bien definido Un proyecto tiene un cliente Un proyecto se lleva a cabo mediante una serie de tareas interdependientes Un proyecto utiliza varios recursos para realizar las tareas Un proyecto tiene un marco de tiempo Un proyecto incluye un grado de incertidumbre Que es un proyecto ? Un proyecto es una iniciativa temporal orientada a crear un producto o servicio único* * Tomado del PMBOK Guide – Fourth EditionPágina - 16 - Material preparado por Hernan Ortiz A. MBA, PMP 8
    • 22/08/2010 Que es la Gerencia de proyectos ? Aplicación de conocimiento, destrezas, herramientas y técnicas a actividades de proyectos para alcanzar sus requerimientos.* * Tomado del PMBOK Guide – Fourth Edition Ciclo de Vida del ProyectoEsfuerzoy Costos Iniciando Organizando Haciendo el Terminar el y Preparando Trabajo el proyecto Proyecto PLAN ACEPTACION ENTREGABLES Tiempo 9
    • 22/08/2010 Ciclo de Vida del Proyecto Alto Influencia de los interesados, riesgos e incertidumbre Costo de los cambiosGrado Bajo Tiempo Ciclo de Vida del Proyecto – La división por fases permite segmentar el proyecto en conjuntos mas fáciles de planear y controlar – Cuando las fases son secuenciales, el cierre de cada fase trae generalmente el cumplimiento de uno o mas entregables – Estos fines de fases permiten evaluar el estado del proyecto y se conocen con varios nombres: hitos, puertas de fases, Kill Points – Una fase es cerrada con la revisión y aceptación de los entregables 10
    • 22/08/2010 Ciclo de Vida del Proyecto• Existen tres tipos de relaciones entre fases – Relación Secuencial o en cascada: una fase arranca cuando la anterior ha terminado – Relación de traslape entre fases: una fase arranca sin haber finalizado la anterior (fast tracking) – Relación de iteración: solo una fase es planeada al tiempo, las siguientes dependen de los resultados y entregables de la primera (ambiente de incertidumbre) Interesados • “Interesados (stakeholders) en el proyecto son personas u organizaciones quienes están activamente involucrados en el proyecto o cuyos intereses pueden verse afectados de manera positiva o negativa por los resultados del proyecto” 11
    • 22/08/2010InteresadosEjercicio de Planeación Proyectos• Cuales son las prácticas para que un proyecto cuente con un buen plan?Ejercicio 1:• En equipos de dos personas, discuta los factores determinantes para que un proyecto cuente con una planeación efectiva• Haga las recomendaciones pertinentes al grupo de manera que se llegue a un consenso. EJ 2 12
    • 22/08/2010 Contenido Programa 1. Alineamiento estratégico 2. Gestión del proyecto de software 3. Levantamiento de requerimientos < 4. Análisis de riesgos en contratación 5. Proceso de Administración de Contratos 6. Aceptación de productos y servicios 7. Cierre y Lecciones Aprendidas Levantamiento de Requerimientos • Muchos de los problemas encontrados en el desarrollo de software se generan debido a la falta de claridad en la recolección de documentación y a la pobre tarea de recolección y validación de los requerimientos entregados por los que finalmente serán usuarios. • Por tanto es necesario tener en cuenta que los requerimientos son el punto clave para marcar la diferencia entre el éxito y fracaso de los proyectos de desarrollo de software.Página - 26 - Material preparado por Hernan Ortiz A. MBA, PMP 13
    • 22/08/2010 Levantamiento de Requerimientos • El *IEEE, en su Standard Glossary of Software Engineering Terminology define un requerimiento como: “Condición o capacidad que tiene que ser alcanzada o cumplida por un sistema o por uno de sus componentes para satisfacer un contrato, un estándar, una especificación u otro documento impuesto formalmente” *The Institute of Electrical and Electronics Engineers, fundado en 1884, entre sus fundadores están: Thomas Alva Edison, Alexander Graham Bell y Frankiln Leonard Pope.Página - 27 - Material preparado por Hernan Ortiz A. MBA, PMP Niveles de Requerimientos Funcionales No-Funcionales Requerimientos de Negocio Documento de Alcance Reglas de Negocio Atributos de Requerimientos de Usuario Calidad Documento Casos Uso Requerimientos de Sistema Interfaces Requerimiento Externas s Funcionales Restricciones Documento RequerimientosPágina - 28 - Material preparado por Hernan Ortiz A. MBA, PMP 14
    • 22/08/2010 Requerimientos de Negocios • Representan los objetivos de alto nivel de la organización o del cliente que requiere el sistema. • Los requerimientos de negocio típicamente provienen del patrocinador principal del proyecto, el cliente, el administrador de los usuarios o el departamento de marketing • Lo que es claro es que los requerimientos de negocio se basan en la visión y objetivos de la compañía y de esta manera se orienta el software esperado.Página - 29 - Material preparado por Hernan Ortiz A. MBA, PMP Requerimientos de Usuario • Describen los objetivos del usuario o tareas que los usuarios deben ser capaces de ejecutar con el producto. • Las formas mas comunes de representar requerimientos de usuario son los casos de uso • Un ejemplo “Hacer una reserva de una aerolínea a través de una página web”Página - 30 - Material preparado por Hernan Ortiz A. MBA, PMP 15
    • 22/08/2010 Requerimientos Funcionales • Especifican la funcionalidad del software que los desarrolladores deben construir en el producto para posibilitar a los usuarios a completar sus tareas y que a su vez satisfagan los requerimientos de negocio. • Algunas veces los requerimientos Funcionales son llamados de comportamiento y normalmente se escriben con la tradicional sentencia “DEBERÁ”. • Un ejemplo de un requerimientos funcional es “El sistema DEBERÁ enviar vía e-mail la confirmación de la reserva al usuario”Página - 31 - Material preparado por Hernan Ortiz A. MBA, PMP Reglas de Negocio • Incluyen políticas corporativas, regulaciones de gobierno, estándares industriales, prácticas contables y algoritmos computacionales. • Estas Reglas de Negocio, no son en si requerimientos de software, ya que estas existen fuera de los límites de cualquier especificación de un sistema de softwarePágina - 32 - Material preparado por Hernan Ortiz A. MBA, PMP 16
    • 22/08/2010 Roles Dentro del proceso de Levantamiento y análisis de requerimientos surgen dos roles vitales para la evolución exitosa de dicho proceso: Cliente e Ingeniero de Requerimientos (IR) Cliente es un individuo u organización de quien derivan directa o indirectamente necesidades para ser cubiertas en un producto de tipo software. Estos clientes solicitan, pagan, seleccionan, especifican, usan y reciben una salida generada por el software.Página - 33 - Material preparado por Hernan Ortiz A. MBA, PMP Características de Excelentes Requerimientos Necesarios. No Ambiguos. Verificables. Completos. Correctos. Viables. Priorizables. Consistentes.Página - 34 - Material preparado por Hernan Ortiz A. MBA, PMP 17
    • 22/08/2010 Evitemos esto…Página - 35 - Material preparado por Hernan Ortiz A. MBA, PMP Requerimientos Necesarios • Cada requerimiento debería documentar algo que el usuario Realmente necesita • Algo que es requerido por un estándar, por variables externas indispensables, o por movimientos del mercado y del negocio. • Es necesario aquel requerimiento que forma parte de un contrato firmado y establecido. • Una manera de identificar requerimientos necesarios, es si la fuente del requerimiento viene de una fuente CON AUTORIDAD para especificar requerimientos • Al revisar un requerimiento, navegue hacia atrás hacia la fuente y valide si son o no necesariosPágina - 36 - Material preparado por Hernan Ortiz A. MBA, PMP 18
    • 22/08/2010 Requerimientos No Ambiguos • Un requerimiento es “no ambiguo” si todos los lectores del requerimiento pueden llegar a una simple y consistente interpretación “igual” del mismo. • Escribir los requerimientos en lenguaje natural, y no en términos computacionales, ayuda que un requerimiento pueda ser interpretado y entendido sin ambigüedades. • Una forma efectiva para revelar ambigüedad es hacer revisiones de los documentos, diagramas, casos de uso, desarrollar prototipos, pintar borradores de interfaces y revisar escenarios de cada uno de ellos • EJEMPLO: “Se requiere implementar en CEN Financiero una funcionalidad que permita almacenar las facturas de los clientes según su necesidad.”Página - 37 - Material preparado por Hernan Ortiz A. MBA, PMP Requerimientos Verificables • Trate de aplicar métodos formales, para realizar pruebas que confirmen que el requerimiento está correctamente especificado. • Debería poderse contar con herramientas que al aplicárselas al requerimiento pueda demostrarse que esté está correctamente especificado • Se puede utilizar, soportes, libros, documentos legales, para verificar el requerimiento. • EJEMPLO:“La resolución 3878 del 28 de Junio de 1996 plantea frente los Reportes de Control Fiscal que: “ las personas que utilicen para el registro de sus bienes o prestación de servicios, sistema P.O.S o factura por computador, deberán imprimir al final del día, el – comprobante informe diario – por cada servidor.”Página - 38 - Material preparado por Hernan Ortiz A. MBA, PMP 19
    • 22/08/2010 Requerimientos Completos. • Requerimientos mal especificados, podrían esconder información que no es fácil de detectar • Puede ayudar a no tener requerimientos incompletos, enfocarse en conocer las tareas del usuario y no sesgarse en las funciones de un sistema. • Si usted sabe que tiene información que falta algo por conocer, utilice estrategia de “marcas” o banderas, lo cual generen tareas “PENDIENTES POR DETERMINAR”. • EJEMPLO : “Se requiere contar con una funcionalidad en la cual el área de soporte u operaciones de E-Business pueda realizar un proceso automático de restauración de las facturas”Página - 39 - Material preparado por Hernan Ortiz A. MBA, PMP Requerimientos Correctos • Cada requerimiento especifica una funcionalidad o condición que debe contener el software • No podemos contar con interpretaciones incorrectas de funcionalidades a implantar • El punto de referencia para validar si un requerimiento es correcto o no, es la fuente del mismo. El usuario directamente, o la documentación de alto nivel que originó el requerimiento pueden determinar si el requerimiento es correcto o no. • Por ello es esencial incluir los usuarios durante el proceso de revisión de los requerimientos • EJEMPLO: “Cuando se desea salir de la aplicación por el vínculo salir el sistema debe enviar al usuario a la página cenmci.xya.biz independiente de la página por la cual ingresó.”Página - 40 - Material preparado por Hernan Ortiz A. MBA, PMP 20
    • 22/08/2010 Requerimientos Viables • Es mas fácil implementar requerimientos cuando se conocen limitaciones técnicas, la capacidad, y las condiciones del ambiente que rodea el proyecto • Para detectar requerimientos “NO VIABLES” es importante incluir dentro del equipo de análisis de requerimientos un miembro de la parte técnica o de ingeniería, así como un miembro del dominio del producto o mercado. • Este tipo de personas, pueden ayudar a determinar de una manera real, que es posible técnicamente o no, o que es excesivamente costoso de implementar. • EJEMPLO:” En el caso de Comfandi se requiere almacenar las facturas por un periodo definido con el cliente de 10 años (1 año en línea y 9 años en medios magnéticos)”Página - 41 - Material preparado por Hernan Ortiz A. MBA, PMP Requerimientos Priorizables. • Si todos los requerimientos tiene el mismo nivel de prioridad, hay una mala identificación y especificación de requerimientos • Cada requerimiento o un conjunto de ellos debe poderse distribuir en los diferentes cortes, fases de liberación de software o producto. • Si todos los requerimientos son de alta prioridad, el equipo de desarrollo no tendrá facilidad para incluir o modificar nuevos requerimientos durante la etapa de desarrollo. • EJEMPLO: Partición por Fases o entregables.Página - 42 - Material preparado por Hernan Ortiz A. MBA, PMP 21
    • 22/08/2010 Requerimientos Consistentes. • Si un requerimiento tiene conflicto con otro requerimiento de software, este requerimiento o ambos tiene problemas en la especificación. • Los requerimientos deben estar acordes con las reglas del negocio y con las variables externas que afectan el dominio del negocio. • EJEMPLO: “Se hace necesario el manejo de un único UNH por archivo plano, tanto en los archivos recibidos como en los generados por CENF ”. • El aplicativo esta en capacidad de recibir documentos con múltiples UNH y abrir tantos documentos como UN llegan.Página - 43 - Material preparado por Hernan Ortiz A. MBA, PMP Redacción de Requerimientos. • Una buena redacción es vital para entendimiento • Buena redacción, facilita interpretación • Redacción estándar, facilita comprensión • La redacción cumple un papel principal en la etapa de validación de requerimientos. • La consistencia en redacción agiliza todos los procesos con los requerimientos (Todos los requerimientos tienen el mismo estilo de redacción)Página - 44 - Material preparado por Hernan Ortiz A. MBA, PMP 22
    • 22/08/2010 Recomendaciones • Se recomienda que en forma narrativa se plasme en un documento lo que el usuario en términos de necesidades exprese, posteriormente analice el documento tratando de segmentarlo en posibles requerimientos. • Extraiga sentencia que contienen palabra “deberá” o “debe” • Busque en cada documento aquellas sentencias que tiene la palabra deberá o debe. • Identifique sentencias que implican requerimientos • Identifique sentencias de tipo verbos , acciones y un resultadoPágina - 45 - Material preparado por Hernan Ortiz A. MBA, PMP Ejercicio Levantamiento de Requerimientos • Conforme equipos de dos personas • En el texto entregado por el profesor, haga un descubrimiento y formalización de los requerimientos de usuario par el proyecto • Entregue un documento al final del ejercicio de 30 minutos • Prepárese para la discusión en plenaria EJ 3Página - 46 - Material preparado por Hernan Ortiz A. MBA, PMP 23
    • 22/08/2010 Redacción de Requerimientos nuevos [LUGAR, TIEMPO, EVENTO, OBJETO] + “debe, deberá, no debe, no deberá” +[ACCIÓN, VERBO, SENTENCIA] + [A QUIEN] +[RESULTADO] • “El sistema en el módulo de ventas debe ofrecer una opción mediante la cual el usuario pueda ver una comparación de lo presupuestado versus la venta real en un rango de fechas para un artículo determinado” • “Cuando el tiempo de conexión exceda el valor predeterminado como máximo el sistema debe cancelar la sesión informándole al usuario que el tiempo se agotó y que por lo tanto será desconectado”Página - 47 - Material preparado por Hernan Ortiz A. MBA, PMP Redacción de Requerimientos nuevos. [LUGAR, TIEMPO, EVENTO, OBJETO] + “debe, deberá, no debe, no deberá” +[ACCIÓN, VERBO, SENTENCIA] + [A QUIEN] + [RESULTADO] • “En caso de que al momento de validar la carga de los archivos se presenten inconsistencias de estructura con respecto a los planos se debe presentar al usuario un mensaje que diga: “La carga no ha sido exitosa puesto que el archivo presenta error de estructura <Causa de la falla de estructura>”.Página - 48 - Material preparado por Hernan Ortiz A. MBA, PMP 24
    • 22/08/2010 Redacción de requerimientos para modificaciones y errores [OPCIÓN, MODULO, EVENTO, OBJETO] + [CONDICIONES, PARAMETROS, AMBIENTE] + [RESULTADO ACTUAL, ERROR, ESTADO] + [ACCIÓN, (CORREGIR, MODIFICAR)] + [RESULTADO ESPERADO, DESTINO] “En el reporte de mercados, al aplicarle filtros por asesor y zona, muestra la información en desorden. Se debe corregir de tal forma que salga ordenado por número de cédula del asesor y agrupado por zona”Página - 49 - Material preparado por Hernan Ortiz A. MBA, PMP Redacción de requerimientos para modificaciones y errores [OPCIÓN, MODULO,EVENTO, OBJETO] + [CONDICIONES, PARAMETROS, AMBIENTE] + [RESULTADO ACTUAL, ERROR, ESTADO] + [ACCIÓN, (CORREGIR, MODIFICAR)] + [RESULTADO ESPERADO, DESTINO] “ Actualmente cuando el usuario comerciante ingresa al pedido sugerido de CENmci el orden de las columnas que se presentan es el siguiente: :“Ajuste Fab.”, “AP”, “Ajuste Com.” , “Días Inv Sug” y en adelante las que siguen, es necesario reorganizar dichas columnas para que los ajustes aparezcan juntos así: “Ajuste Fab.” “Ajuste Com.” “AP”, “Días Inv Sug” y en adelante las que siguen.Página - 50 - Material preparado por Hernan Ortiz A. MBA, PMP 25
    • 22/08/2010 Contenido Programa 1. Alineamiento estratégico 2. Gestión del proyecto de software 3. Levantamiento de requerimientos 4. Análisis de riesgos en contratación < 5. Proceso de Administración de Contratos 6. Aceptación de productos y servicios 7. Cierre y Lecciones Aprendidas Riesgos en Proyectos de Software Un riesgo de un proyecto es un evento o condición inciertos que, si se produce, tiene un efecto negativo sobre al menos un objetivo del proyecto, como tiempo, costo, calidad o alcance Alcance Costo TiempoPágina - 52 - Material preparado por Hernan Ortiz A. MBA, PMP 26
    • 22/08/2010 Gerencia del Riesgo Riesgos en Proyectos de Software Planeación Ejecución Valor Comprometido Riesgo Oportunidad Ciclo de Vida del ProyectoPágina - 53 - Material preparado por Hernan Ortiz A. MBA, PMP Gerencia del RiesgoPágina - 54 - Material preparado por Hernan Ortiz A. MBA, PMP 27
    • 22/08/2010 Riesgos en Proyectos de Software • Los riesgos existen en todos los proyectos y la probabilidad de que ocurran depende de su naturaleza • El riesgo del proyecto tiene su origen en la incertidumbre • Riesgos conocidos son aquellos que han sido identificados y analizados y que pueden ser planeados • Los riesgos desconocidos no pueden ser gestionados de forma proactiva y una respuesta prudente, puede ser asignar una contingencia generalPágina - 55 - Material preparado por Hernan Ortiz A. MBA, PMP Identificación de Riesgos • La identificación del riesgo es un proceso iterativo a lo largo del ciclo de vida • El equipo del proyecto debe participar en el proceso para desarrollar y mantener un sentido de pertenencia y responsabilidad por los riesgos 28
    • 22/08/2010 Identificación de Riesgos • Las herramientas mas comúnmente usadas: Revisión de documentación Técnicas de recopilación de información, como tormenta de ideas, delphi, entrevistas, Ident. de causa y DOFA Análisis mediante lista de chequeo Análisis de supuestos Técnicas de diagramaciónPágina - 57 - Material preparado por Hernan Ortiz A. MBA, PMP Identificación de Riesgos • Categorías de riesgos que ayudan a identificar más riesgos: Externas Internas Impredecibles Predecibles Financiero Cronograma Técnico Legal Externas: más allá del equipo de proyecto Internas: dentro del control del equipo de proyectoPágina - 58 - Material preparado por Hernan Ortiz A. MBA, PMP 29
    • 22/08/2010 Identificación de Riesgos en Contratación de Software Ejercicio de diagramas de afinidad para agrupar riesgos: – Haga una tormenta de ideas – Coloque los eventos de riesgos en pequeños pedazos de papel – Examine los eventos de riesgo – Los miembros del equipo individualmente y en forma simultanea ponen los eventos de riesgo agrupados en la pared – El proceso termina hasta que no son hechos mas movimientos por el equipo – Los miembros del equipo deciden los nombres de cada agrupación EJ 4Página - 59 - Material preparado por Hernan Ortiz A. MBA, PMP Análisis de Riesgos en Contratación • El análisis cualitativo de riesgos es una forma de determinar la importancia de tratar riesgos específicos y guiar las respuesta de los mismos • El análisis cualitativo requiere que la probabilidad y el impacto de los riesgos sean evaluados usando métodos y herramientas cualitativasPágina - 60 - Material preparado por Hernan Ortiz A. MBA, PMP 30
    • 22/08/2010 Análisis de Riesgos en Contratación • Entradas al análisis cualitativo: – Lista de riesgos identificados – Estado del proyecto – Tipo de proyecto (complejidad=mayor incertidumbre) – Precisión de la información – Escala de probabilidad e impacto – SupuestosPágina - 61 - Material preparado por Hernan Ortiz A. MBA, PMP Análisis de Riesgos en Contratación • Probabilidad e impacto del riesgo – Probabilidad es la posibilidad de un riesgo pueda ocurrir – Impacto o consecuencia del riesgo es el efecto sobre los objetivos del proyecto si el suceso de riesgo ocurrePágina - 62 - Material preparado por Hernan Ortiz A. MBA, PMP 31
    • 22/08/2010Análisis de Riesgos en Contratación • Matriz de probabilidad e impactoRiesgo Categoría Probabilidad Impacto Factor Respuesta Riesgo Priorice los riesgos, nunca hay bastante tiempo o dinero para responder a todos los riesgos Contenido Programa 1. Alineamiento estratégico 2. Gestión del proyecto de software 3. Levantamiento de requerimientos 4. Análisis de riesgos en contratación 5. Proceso de Administración de Contratos < 6. Aceptación de productos y servicios 7. Cierre y Lecciones Aprendidas 32
    • 22/08/2010 Proceso de Administración de Contratos Status, issues, results PMC of process and product evaluations; Corrective measures and analyses action Replan What Corrective action to monitor Status, issues, What to build results PP What to do of progress and milestone Commitm Engineering and Support ents reviews process areas Plans Measurement needs SAM Supplier agreement Product component requirements, technical issues, Supplier completed product components, acceptance reviews and tests ® 2002 by Carnegie Mellon University ® 2002 by Carnegie Mellon UniversityPágina - 65 - Material preparado por Hernan Ortiz A. MBA, PMP Proceso de Administración de ContratosSG 1: Establecer los contratos con los proveedores SP 1.1 SP 1.3 SP 1.2 Determinar Establecer los Seleccionar los tipos de contratos con los proveedores adquisisiones los proveedores Requerimientos Contratos con Productos del proveedor los proveedores PI SP 2.3 SP 2.2 SP 2.4 SP 2.1 Aceptar los Ejecutar los Realizar la Revisar los productos acuerdos con transición de productos adquiridos los proveedores los productosSG 2: Cumplir los contratos con los proveedores ® 2002 by Carnegie Mellon UniversityPágina - 66 - Material preparado por Hernan Ortiz A. MBA, PMP 33
    • 22/08/2010 Proceso de Administración de Contratos • El proceso puede utilizar varios tipos de documentos: – RFI (request for information) Requerimiento de información – se utiliza para solicitar información antes de una propuesta formal – RFQ (request for quotation) Requerimiento de una cotización para una necesidad precisa – RFP (request for proposal) Requerimiento de propuestas o licitación a través del cual una organización invita a proveedores potenciales – SOW (statement of work) Descripción de la necesidad de la organización cliente para dar entendimiento a los proponentes. Pueden incluir descripción de requerimientos – Plantillas de contratos – Matrices de evaluación de alternativasPágina - 67 - Material preparado por Hernan Ortiz A. MBA, PMP Definición de Contrato/Acuerdo • Un contrato es un documento legal que vincula a un comprador y a un vendedor, mediante el cual el vendedor se obliga proveer los productos y servicios y el comprador se compromete a pagarlosPágina - 68 - Material preparado por Hernan Ortiz A. MBA, PMP 34
    • 22/08/2010 Definición de Proveedor / Vendedor • Una entidad que entrega productos o ejecuta los servicios adquiridos. • Un individuo, sociedad, compañía, corporación, asociación u otra entidad que tiene un acuerdo (contrato) con un comprador para el diseño, desarrollo, construcción, modificación o suministro de ítems bajo los términos de un acuerdo ó contratoPágina - 69 - Material preparado por Hernan Ortiz A. MBA, PMP Definición de Contrato Un contrato tiene los siguientes elementos: • Intensión de entrar en una relación • Una oferta y su aceptación • Un pago o valor a cambio • Capacidad de entender los términos y condiciones • Términos y condiciones legales 35
    • 22/08/2010Tipos de Contrato • Costos reembolsables mas un valor de utilidad • Precio Fijo – precio fijo es el mas común de todos • Precio fijo e incentivo • Tiempo y materiales – Valor fijo por unidad de tiempoEjercicio Tipos de Contratos Costos Reembolsables Precios Fijos Ventajas Desventajas Ventajas Desventajas EJ 5 36
    • 22/08/2010 Criterios de Decisión al Contratar Software • Situación Financiera • Experiencia • Casos de Éxito y experiencias • Experiencia específica • Recursos locales • Soporte e infraestructura • Calificación técnica de los desarrolladores • Metodologías utilizadas (madurez en sus procesos) • Gestión de proyecto propuesta • Planes de calidad y transición • Precios • Tiempo de entregaPágina - 73 - Material preparado por Hernan Ortiz A. MBA, PMP Contenido Programa 1. Alineamiento estratégico 2. Gestión del proyecto de software 3. Levantamiento de requerimientos 4. Análisis de riesgos en contratación 5. Proceso de Administración de Contratos 6. Aceptación de productos y servicios < 7. Cierre y Lecciones Aprendidas 37
    • 22/08/2010 Objetivos de la Aceptación • Se busca dejar constancia de manera formal que “el producto de software o componente adquirido cumple con la funcionalidades o uso para le cual fue adquirido en el ambiente previsto.”Página - 75 - Material preparado por Hernan Ortiz A. MBA, PMP Criterios de Aceptación • Los criterios de aceptación del software deben estar definidos y acordados en el contrato. • Ejemplos de estos criterios son las pruebas de aceptación, las cuales por lo general se centran en la funcionalidad • Deben existir pruebas técnicas (integración y de carga o desempeño) y pruebas de usuarios asociada a la funcionalidad • Las pruebas de aceptación son responsabilidad de los usuarios del lado cliente • Es ideal que los datos de pruebas sean preparados y entregados por el clientePágina - 76 - Material preparado por Hernan Ortiz A. MBA, PMP 38
    • 22/08/2010 Criterios de Aceptación(2) • Algunas recomendaciones para aceptar software: ⁻ Los requisitos deben ser acordados por las dos partes en un documento formal ⁻ Se debe hacer un manejo de control de cambios, para mantener actualizados los requisitos del proyecto ⁻ Es necesario contar con toda la documentación del software (técnica y de usuario) ⁻ Si existe un servicio de soporte o periodo de garantía, es indispensable definir un acuerdo de niveles de servicio, el cual determina las características y alcance de este servicioPágina - 77 - Material preparado por Hernan Ortiz A. MBA, PMP Proceso de Validación (CMMI) RD SG 1: Preparar la validación SP 1.3 SP 1.1 SP 1.2 Establecer los Seleccionar los Establecer el criterios y los productos de ambiente de procedimientos trabajo a validar validación de validación Ambiente de validación Procedimientos y criterios de validación Lista de productos de trabajo seleccionados SP 2.2 SP 2.1 Analizar los Realizar la resultados de la validación validación Reportes de validación Resultados de la validación Matriz de referencias cruzadas Reportes de deficiencias Log de ejecución procedimientos Hallazgos de la validación Demostraciones operacionales Requerimientos de cambio SG 2: Validar el producto o sus componentes ® 2002 by Carnegie Mellon UniversityPágina - 78 - Material preparado por Hernan Ortiz A. MBA, PMP 39
    • 22/08/2010 SP 1.1 – Seleccionar los Productos para Validar • Seleccionar los productos y componentes del producto a ser validados y los métodos que á usar con cada uno de ellos. • La selección se basa en la relación de los productos y los componentes con las necesidades del usuario. • Para cada componente debiera determinarse el ámbito de la validación (e.g., comportamiento operacional, mantención, entrenamiento o interfaz con el usuario, etc.).Página - 79 - Material preparado por Hernan Ortiz A. MBA, PMP SP 1.1 – Seleccionar los Productos para Validar Productos de trabajo típicos: 1. Lista de productos y componentes seleccionados para validación. 2. Métodos de validación para cada producto o componente. 3. Requerimientos para la ejecución de la validación de cada producto o componente. 4. Restricciones de validación para cada producto o componente. Subprácticas: 1. Identificar los principios claves, las características y las fases de validación del producto o sus componentes a través de la vida del proyecto.Página - 80 - Material preparado por Hernan Ortiz A. MBA, PMP 40
    • 22/08/2010 SP 1.2 – Establecer el Ambiente de Validación • Establecer y mantener el ambiente necesario para soportar la verificación. • Los requerimientos para el ambiente de validación: – dependen de: • el producto o componentes seleccionados, • el tipo de productos de trabajo (e.g., diseño, prototipo, versión final), y • los métodos de validación; – pueden determinar requerimientos de compra o desarrollo de equipos, software u otros recursos; – que son enviados a los procesos de desarrollo de requerimientos para su proceso. • Si se determina el re-uso de recursos existentes, se deben realizar los arreglos necesarios.Página - 81 - Material preparado por Hernan Ortiz A. MBA, PMP SP 1.2 – Establecer el Ambiente de Validación Productos de trabajo típicos: 1. Ambiente de validación. Subprácticas: 1. Identificar los requerimientos del ambiente de validación. 2. Identificar los productos provistos por el cliente. 3. Identificar los ítems a re-usar. 4. Identificar las herramientas y equipos de prueba. 5. Identificar los recursos de validación disponibles para re-uso y modificación. 6. Planificar en detalle la disponibilidad de recursos.Página - 82 - Material preparado por Hernan Ortiz A. MBA, PMP 41
    • 22/08/2010 SP 1.3 - Establecer los Procedimientos y Criterios de Validación (1) • Establecer y mantener los procedimientos y los criterios de validación. • Se definen para asegurar que el producto o sus componentes cumplirán su uso previsto en el ambiente previsto. • Las necesidades de procedimientos de validación se pueden satisfacer con casos y procedimientos de pruebas de aceptación. • Incluyen la prueba y evaluación de los servicios de mantención, entrenamiento y soporte. • Ejemplos de fuentes de criterios de validación: – Requerimientos del producto y sus componentes. – Estándares. – Criterios de aceptación del cliente. – Desempeño ambiental. – Umbrales de desviación del desempeño.Página - 83 - Material preparado por Hernan Ortiz A. MBA, PMP Contenido Programa 1. Alineamiento estratégico 2. Gestión del proyecto de software 3. Levantamiento de requerimientos 4. Análisis de riesgos en contratación 5. Proceso de Administración de Contratos 6. Aceptación de productos y servicios 7. Cierre y Lecciones Aprendidas < 42