Estimación de Proyectos de Software: Intro

Hola estimado Internauta, gracias por pasar por mi blog. Si es que estás leyendo esto, es que más de alguna vez te has encontrado, lidiado o conoces sobre proyectos en los que no se cumple con las fechas de entrega, donde no se cumple con el cronograma, o donde hay sobrecostos. 

Por otra parte, yendo al principio, la estimación es una actividad que todos encontramos en nuestro día a día, por ejemplo cuando nos trasladamos desde nuestro hogar hasta el trabajo, estimamos cuánto tiempo nos tomará. Cuando vamos construir un casa, probablemente queremos saber cuanto nos costará y en cuanto tiempo estará lista. 

Hay muchos retos alrededor de este tema, relacionados con estimar con precisión proyectos de software. Existen estándares y técnicas que nos ayudarán a abordar este tema, respecto a lo cual señalaré en este artículo algunas de las mejores prácticas.

Es necesario pensar la estimación como un proceso dinámico, en el cual tenemos como entrada la experiencia o datos históricos de proyectos anteriores y que nos sirven para crear una línea base de estimación. En la medida que va avanzando el proyecto se requiere gestionar la estimación, es decir si el contexto del proyecto ha cambiado, es decir el contexto, entonces la estimación debe actualizarse. Por otra parte toda esa nueva información sirve de retroalimentación para ajustar nuestro proceso de estimación.

Para estimar el esfuerzo debemos considerar varios pasos, comenzando por la estimación del tamaño, paso en el cual se acota el alcance y se define la "cantidad de trabajo" que se requiere realizar, por ejemplo en términos de un local de comida rápida, tendríamos que se require cocinar 50 hamburguesas especiales; para cocinar esas hamburguesas (como proyecto, es decir un pedido único), procedemos posteriormente a definir cual es el esfuerzo requerido para cocinar ese pedido, por ejemplo 200 horas - persona. Luego dependiendo del tiempo que dispongamos podemos asignar más o menos recursos para finalmente obtener la duración.

Respecto a la caricatura anterior, para el proceso de estimación, podemos considerar como input la experiencia de los cocineros, es decir utilizar su juicio experto, o Dephi, consultándole a varios cocineros, estimar en términos de pedidos anteriores es decir Analogía, o utilizando alguna fórmula en base estimaciones anteriores, o desglosando las actividades, o simplemente considerar una estimación top down de alto nivel. ¿Cómo sabemos cuál es la mejor alternativa para estimar nuestro proyecto?

A continuación recomiendo un excelente video de referencia:

• http://www.youtube.com/watch?v=boAT_ChVEfo

BI en el sector de Servicios Financieros

Cualquier entidad financiera que quiera competir en el mundo global debe comprender y definir sus objetivos de negocio con la claridad. Por otra parte unos clientes más exigentes, cambios rápidos, fuerte competencia y márgenes cada vez más pequeños, exigen al sector bancario estar a la vanguardia tecnológica.

Una solución tecnológica capaz de desarrollar el potencial de una organización que cubre desde la planificación estratégica, y pasa desde la contabilidad financiera, hasta el control de gestión en la empresa evidentemente permitiría un mejor manejo de ganancias, riesgos, relaciones con los clientes y control de cuentas en forma totalmente integrada en un sistema de gestión completo y seguro. 

El mercado ofrece diversas soluciones comerciales que cuando están alineadas con el negocio y sus políticas (IT Governance), proveen un ambiente muy potente para el manejo de todos los aspectos de una organización financiera.

Un sistema de BI vendría a cubrir éstas necesidades en sector financiero. Desde la perspectiva interna, se requiere de un sistema de gestión bancario completo e integrado (Ej. Balanced Scorecard + BI) que ayude a aumentar la rentabilidad a través de decisiones mejor informadas sumado a un enfoque sistémico de: 

• La rentabilidad de los canales de distribución 
• Las unidades organizacionales 
• Los productos 
• Los clientes 

Está el caso de BBVA que con el objetivo de tener al cliente en el centro de toda su actividad (Customer Centric), el Grupo global de servicios financieros BBVA ha seleccionado a MicroStrategy como plataforma corporativa de Business Intelligence tras un ESTRICTO proceso de selección, herramienta ya avalada por los buenos resultados que arrojaron los números respecto a su rentabilidad en el 2011. Desde el año 2008, BBVA inició laboralmente una revisión global de sistemas de soporte a la toma de decisiones, incluyendo las áreas de operaciones, pre-venta, ventas, finanzas, marketing y análisis de riesgos, llegando a la conclusión de sustituir las herramientas de reporting existentes por una plataforma de BI con el objetivo de ofrecer al Grupo una versión única de los datos de negocio (tras proceso ETL y limpieza en datos), habiendo proporcionado conocimiento y levantado las alertas en el momento adecuado para responder a los requisitos de la directiva y reducir los costos e impactos operacionales.

Pronto verán la luz los próximos proyectos BI en Chile que responden como contrademanda a líneas de aplicaciones ya deprecadas. Esta primera fase solo es la punta del iceberg y dará paso a nuevas  prestaciones para las multinacionales, por ejemplo para medir y codificar mejor los procesos de un Banco, jugando adelantado y garantizando los resultados antes de expandirse. 

Concluyendo, respecto a la implementación existen empresas que ofrecen soluciones customizables, y comento como Tip que podrían establecer prácticas para el desarrollo con un framework Open Source para agilizar y mejorar la calidad de los productos, lo cual no implica compartir fuentes, pero que sí fortalece la marca (Caso RedHat). 

MASHUP:
http://www.latcapitalsoluciones.com/soluciones-industria/banca-y-servicios-financieros/
http://www.techweek.es/business-intelligence/soluciones-negocio

Proyectos TI: Valor Organizacional

La idea de gestión de proyectos ha estado con nosotros desde hace mucho, mucho tiempo. De hecho, ésta idea ha estado con nosotros antes que las grandes pirámides de Egipto fueran construidas. Hoy en día, la gestión de proyectos ha emergido en su propia área, teniendo como fundamentos un cuerpo de conocimiento e investigación en muchas disciplinas. Aunque aún es relativamente reciente el campo del MIS (Gestión de Sistemas de Información) y la Ingeniería de Software, tienen sus propios “cuerpos de conocimiento”, que incluyen varias herramientas, técnicas y métodos apoyados por una creciente base de investigaciones.

Desafortunadamente, la historia para los proyectos TI no ha sido exitosa como uno hubiera esperado, aunque la situación parece estar mejorando. Una razón para estas mejoras ha sido un mayor enfoque en la gestión de proyectos para apoyar las actividades requeridas para desarrollar y entregar sistemas de información.

Construir un sistema es más que sentarse en frente de un computador y escribir código, la gestión de proyectos es más que crear bonitos diagramas o diagramas utilizando uno u otro software para la gestión de proyectos.

Por otra parte, construir un sistema es un éxito desde una perspectiva técnica, pero puede ser un fracaso a nivel de la organización. Los sistemas de información –el producto de los proyectos TI- implican un cambio organizacional planificado. Las TI son un facilitador para nuevos productos, servicios, y procesos que pueden cambiar las relaciones existentes entre una organización y sus clientes o proveedores, así como entre las personas dentro de la organización.

Este cambio puede representar una amenaza a muchos grupos. Por lo tanto, la gente no necesariamente será receptiva a nuevos sistemas de información, independiente de lo bien que hayan sido construidos, o que tan avanzada sea la tecnología, herramienta y técnicas. En la otra mano, las personas en una organización pueden legítimamente resistirse a utilizar sistemas de información que no funcionan apropiadamente, o que no satisfacen sus necesidades como esperaban. Por ende, debemos adoptar un enfoque que no considere el aspecto técnico sobre el organizacional, o viceversa. Atender a ambos aspectos, técnico y organizacional de los proyectos TI, debe estar balanceado con tal de lograr un proyecto exitoso.

Pero, ¿qué es un proyecto exitoso? Muchas personas y autores definen un proyecto exitoso en términos de un proyecto completado dentro del plazo y dentro del presupuesto. No voy a argumentar que la

realización de un proyecto en el plazo previsto y con los recursos asignados no sea importante. Sin embargo, completar los proyectos dentro del plazo y presupuesto, son condiciones importantes, pero no necesariamente suficientes, si lo que el cliente recibe no era lo que esperaba.

Un proyecto que aporta valor -medible- a la organización, define que proyectos serán evaluados como exitosos. Por otra parte este enfoque alinea la gestión de proyectos de TI y los conceptos, herramientas y técnicas relacionadas, así enmarca las decisiones a tomar desde la concepción hasta el cierre de un proyecto.

EXTRACTO:

John Wiley & Sons - Information Technology Project Management; Providing Measurable Organizational Value - 2002

Conceptos de Gestión TI

El papel clave que tienen las tecnologías de la información y la innovación en el desarrollo y sostenimiento de la competitividad de empresas y países, está generando un cambio en las prácticas de gestión empresarial. De allí se pasa a identificar las funciones y actividades propias tales como la prospectiva, planeamiento tecnológico, innovación tecnológica, desarrollo y transferencia de tecnología. La búsqueda deliberada y sistemática de innovaciones y el uso intensivo del conocimiento como factores dominantes y responsables del éxito de las empresas, están promoviendo a la gestión tecnológica como la función motora e integradora de las estrategias de desarrollo empresarial. 

Algunos conciben este sistema como "una colección de métodos sistemáticos para la gestión de procesos de aplicación de conocimientos, extender el rango de actividades humanas y producir bienes y servicios" (Kanz and Lam, 1996). Mientras otros, como el National Research Council (NRC) de EEUU, lo considera como los conocimientos integrados de "ingeniería, ciencias y disciplinas del área de gestión, para planear, desarrollar e implementar capacidades tecnológicas en el diseño y el logro de los objetivos estratégicos y operacionales de una organización" (Khalil, 1998). 

Se mencionan a continuación algunos conceptos asociados a la gestión de las tecnologías de la información y especifican procesos, elementos y funciones básicas para definir una Estrategia TI en la empresa:

1. IT Governance+Balanced Scorecard (Estrategia, Políticas)
2. PMBOK (Gestión, Táctica)
3. SGC: BPM+CMMi+Ingeniería/UML+ISO9001+ITIL (Procesos, Operaciones)

La relación entre estos conceptos, modelos y teorías nos aportan en los procesos de toma de decisiones y ejecución de acciones relacionados con las tecnologías de la información en la empresa y organizaciones.

REFERENCIAS:

• http://jaibana.udea.edu.co/producciones/Heberto_t/gestion_teno_dllo_tecno.html
• http://www.monografias.com/trabajos21/gestion-tecnologica/gestion-tecnologica.shtml

PMBOK a secas

El Project Management Institute (PMI®) detectó en el año 1969 grandes falencias en la Dirección de Proyectos a nivel mundial. En 1987, el PMI publicó la primera edición del PMBOK® como una guía para satisfacer la necesidad de disponer de un marco teórico en la disciplina de Dirección de Proyectos. 

La Guía de los fundamentos de la dirección de proyectos (más conocida como PMBOK®) es un estándar ampliamente reconocido para gestionar y administrar proyectos. La misma comprende dos grandes secciones, la primera sobre los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento específico para la gestión de un proyecto e incluye prácticas tradicionales comprobadas y ampliamente utilizadas, así como prácticas innovadoras que están emergiendo en la profesión, incluyendo material publicado y no publicado. Como consecuencia, los Fundamentos de la Dirección de Proyectos están en constante evolución.

El objetivo principal de la Guía del PMBOK® es identificar el subconjunto de Fundamentos de la Dirección de Proyectos generalmente reconocido como buenas prácticas. Identificar significa proporcionar una descripción general en contraposición a una descripción exhaustiva. Generalmente reconocido significa que los conocimientos y las prácticas descritos son aplicables a la mayoría de los proyectos, la mayor parte del tiempo, y que existe un amplio consenso sobre su valor y utilidad. Buenas prácticas significa que existe un acuerdo general en que la correcta aplicación de estas habilidades, herramientas y técnicas puede aumentar las posibilidades de éxito de una amplia variedad de proyectos diferentes. Buenas prácticas no quiere decir que los conocimientos descritos deban aplicarse siempre de forma uniforme en todos los proyectos; el equipo de dirección del proyecto es responsable de determinar lo que es apropiado para cada proyecto determinado.

"La finalidad del PMBOK®, entonces, no es la de exponer las disciplinas, técnicas y experiencias aplicables a la dirección de proyectos, sino simplemente la de identificar el subconjunto de éstas que es generalmente reconocido como buenas prácticas" 

Para que estas buenas prácticas sean asequibles, el PMBOK® divide el conjunto de conocimientos para la dirección de proyectos en cuatro grupos de procesos: todo proyecto, así como sus distintas fases e iteraciones tiene que transitar por una serie de actividades de inicio, planeación, ejecución y cierre.

Existen otras normas sobre madurez de la dirección de proyectos de la organización (CMMi), características del equipo humano y otros temas donde las normas sobre dirección de proyectos no abordan la totalidad de los detalles de cada tema. Hay varias razones por las cuales una norma no trata un cierto tema: puede estar incluido en alguna otra norma relacionada; puede ser tan general que no haya nada que se aplique únicamente a la dirección de proyectos; o no existe consenso suficiente acerca de un tema. La falta de consenso significa que hay diversas opiniones dentro de la profesión acerca de cómo, cuándo o en qué parte de la organización, y quién dentro de ella, debe llevar a cabo esa actividad específica de dirección de proyectos. La organización o el equipo de dirección del proyecto debe decidir cómo se van a tratar esas actividades en el contexto y las circunstancias del proyecto para el cual se está usando la Guía del PMBOK®. Puesto que se trata de una guía, más que de una metodología usar diferentes metodologías y herramientas para implementar el marco de referencia y comprender mejor el más amplio contexto en el cual se realizan los proyectos.

Actualmente la creciente aceptación de la dirección de proyectos indica que la aplicación de conocimientos, procesos, habilidades, herramientas y técnicas adecuados puede tener un impacto considerable en el éxito de un proyecto. La Guía del PMBOK® también proporciona y promueve un vocabulario común en el ámbito de la profesión de la dirección de proyectos, para analizar, escribir y aplicar conceptos de la dirección de proyectos, además de en el Code of Ethics and Professional Conduct del Project Management Institute se precisa las obligaciones básicas de responsabilidad, respeto, imparcialidad y honestidad. Requiere que quienes se desempeñan en este ámbito demuestren compromiso con la conducta ética y profesional.

PMBOK 5, más ágil que nunca

Hace unos días el PMI (www.pmi.org) ha liberado el “Exposure Draft“ de la siguiente versión 5 del PMBOK (A Guide to the Project Management Body of Knowledge). El objetivo de este documento es presentarlo a los profesionales miembros del PMI para que la revisen y generen sus comentarios.

Encuentro muy interesante que en el 2011 existiendo una mayor madurez de las metodologías ágiles, estas se comiencen a integrar como alternativas respecto al ciclo de vida de los proyectos, en lo que sería la gestión de proveedores.


Respecto a los cambios en los Procesos y Areas de Conocimiento, quizás lo más importante es que se ha añadido una nueva área de conocimiento, denominada “Project Stakeholder Management“, que tiene el código 13, con los siguientes procesos:

• 13.1 Identificar a los Interesados (que en la versión de la Guía para el PMBOK(r) pertenecía al capítulo 10,  Gestión de las Comunicaciones del Proyecto.
• 13.2 Planificar la Gestión de los Interesados
• 13.3 Plan la relación con los interesados (Plan Stakeholder ENGAGEMENT). Realmente la palabra Engage, es más que relación (mi traducción). En inglés se usa la palabra ENGAGE al momento de COMPROMETERSE en matrimonio.
• 13.4 Gestionar la relación con los interesados (Manage Stakeholder Engagement)
• 13.5 Controlar la Relación con los Interesados (Control Stakeholder Engagement)

Otra novedad muy importante es que ahora se ha formalizado el desarrollo de los planes para la gestión de los alcances, tiempos, y costos, que en la versión anterior se exigía pero estaba inserta en la introducción a dichos capítulos. Es decir, ahora tenemos los nuevos procesos,

• 5.1 Planificar la Gestión de los Alcances.  Aquí se ha añadido un ejemplo de una matriz para la trazabilidad de los requerimientos.
• 6.1 Planificar la Gestión del Cronograma
• 7.1 Planificar la Gestión de los Costos

Los contenidos de dichos planes son los mismos básicamente que en la versión anterior.

Otro elemento importante es el ítem 1.6 Valor del Negocio (1.6 Business Value).  Esta nueva sección de dos páginas trata la importancia del proyecto de generar valor para las organizaciones como objetivo principal. De nada sirve terminar a tiempo, cumpliendo los presupuestos, etc. si el proyecto no añade valor a la organización.

En el capítulo de Alcances, el proceso que anteriormente se denominaba Verificar el Alcance, ha sido re-nombrado como “Validar el Alcance“.

Si usted tiene algún comentario sobre la nueva versión de este estándar, puede ingresar a la página web del PMI y enviar dichos comentarios.

REFERENCIAS:

• http://www.allaboutagile.com/agile-project-management-extending-pmbok/
• http://www.velociteach.com/2012/02/thoughts-on-the-5th-edition-pmbok-guide-exposure-draft/
• http://www.pmi.org/PMBOK-Guide-and-Standards/Standards-Library-of-PMI-Global-Standards.aspx

CMMi y la Necesidad de un Modelo Integrado

A mediados de la decada los 80' se hizo evidente para el Departamento de Defensa de los Estados Unidos de que la gran cantidad de sistemas que se estaban desarrollando para aplicaciones de defensa que eran intensivos en software, no estaban cumpliendo con los requisitos establecidos y se estaban elevando descontroladamente los costos.

El Software Engineering Institute (SEI), como parte de la Carnegie Mellon University, fue fundado por el Departamento de Defensa como un centro de para la investigación y desarrollo, con la misión de liderar y promover las prácticas de la Ingeniería de Software para mejorar la calidad de los sistemas basados en software.

Inicialmente el modelo se enfocó predominantemente en los procesos de Ingeniería de Software. Las actividades del ciclo de vida del software que coincidían con las descripciones encontradas en la ISO9001:1994 fueron colocadas todas juntas en una Area de Proceso Clave (Key Process Area) llamada Ingeniería de Producto.

Muchos debates tomaron lugar en los sagrados salones del SEI durante el desarrollo del CMMI v1.0 con respecto a la necesidad de una descripción más detallada de las actividades del ciclo de vida versus mantener un cierto tamaño y un número de Areas de Proceso Claves que fueron desarrolladas en el Nivel 3 de Madurez. Al final, se decidió mantener sólo una Área de Proceso Clave llamada "Ingeniería" donde se describen las actividades o funciones que se mantendría compatibles con el resto de KPA en CMM.

Mientras el uso de CMM crecía rápidamente alrededor del mundo, comenzó a verse clara y rápidamente que el foco estricto en la Ingeniería de Software, no satisfacía las necesidades de negocio o sistemas intensivos en software. Una asesoría conducida por Jeff Perdue del Institute of Software Process Improvement (ISPI) mostró que la necesidad por un proceso de mejora de "sistemas" de ingeniería era inmediata y los resultados serían precisos. Finalmente varios modelos CMM fueron desarrollados para una gran variedad de disciplinas, aparte de la ingeniería de software. Estos modelos incluidos para la adquisición de software, la gestión de personas, desarrollo y la integración de producto y procesos.

Aunque estos modelos resultaron útiles para muchas organizaciones, el uso de múltiples modelos también se convirtió en un problema. Las organizaciones que deseaban centrarse en su mejora en todas las disciplinas tuvieron dificultades. Las diferencias entre los modelos específicos de cada disciplina, incluyendo sus arquitecturas, contenidos y enfoques, limitaban la habilidad de las organizaciones para enfocar sus esfuerzos en mejorar sus procesos exitosamente. Adicionalmente, la aplicación de múltiples modelos que no estaban consistentemente integrados dentro y a través de una organización, resultaba en altos costos en términos de capacitación, evaluaciones y actividades de mejora.

El proyecto CMMi fue formado para superar el problema de usar múltiples CMM. La misión del equipo del modelo CMMi fue combinar tres modelos:

1. SW-CMM: Capability Maturity Model for Software (v2.0 draft C).
2. Electronic Industries Alliance Interim Standard (EIA/IS 731).
3. Integrates Product Development Capability Maturyty Model (IPD-CMM v0.98)

En definitiva, el objetivo era integrar estos modelos en un único framework para su uso por organizaciones que persiguen en toda la empresa la mejora de sus procesos.

La necesidad de un modelo integrado se puede apreciar en como evolucionó CMMi en el set de modelos que representa hoy en día.

REFERENCIAS:

• Introduction to the Architecture of the CMMI® Framework
• Addison Wesley - CMMI for Development 3rd Edition Mar 2011
• Addison Wesley Professional - CMMI for Services - Guidelines for Superior Service - 2nd Edition - Mar 2011
• Practical Insight into CMMI