Category / Proyectos de Software
Un STAKEHOLDER, es un individuo cuyo interes se ve afectado positivamente o negativamente a raiz del proyecto que se esta realizando. Por mencionar ejemplos, tendriamos:
>Cliente
>Gerente de proyecto
>Sponsor(Patrocinador)
>Equipo
>Organizacion
>Otras areas involucradas
Primero quiero empezar este post enfocándome en las metodologías que existen para construir un producto de software:
>Gestión de proyectos de Software
>Desarrollo de software (ciclo de vida del software)
>Mantenimiento del software (poco o casi nunca utilizadas)
En las metodologías de proyectos de software nos enfrentaremos con los famosos “ENTREGABLES” (formatos, plantillas). Pero lo que existe en este tipo de metodologías esencialmente son: roles, etapas, fases, etc.
Al menos si usas la suite de rational (RequisitePro, ClearQuest, etc) ya vienen listos los generadores de plantillas y con la capacidad de integrarse con la suite de office.
Entonces son los miembros del equipo (personas) del proyecto de software vuelven a diseñar los formatos, redefinen, agregan, quitan cosas de lo que se le conoce como entregable. Aquí es donde se identifica el primer problema, ya que estas personas no son los creadores originales de estos formatos y es donde se empiezan a ver deficiencias al momento de completarlos, desarrollarlos, etc.
Ahora es que quiero resaltar lo siguiente “Las metodologías de gestión son importantes por que éstas
implementan la manera, la forma, del cómo trabajar los proyectos software. Quizá sin saberlo lo que hacemos al definir una metodología es establecer él o los procesos de cómo vamos a trabajar los
proyectos software. Tener una metodología es muy importante por que el proceso queda definido, estructura, homogeneizado e incluso da sentido de pertenencia a cada elemento. Los resultados serán productos software: Planes, actas, software, manuales, casos de pruebas, etc.”
Entonces podemos darnos cuenta que las metodologías de gestión son importantes, muchas veces me ha sucedido y he preguntado que tipo de metodología usan en tu empresa, lo primero que he escuchado es toda la descripción de la metodología y siempre el pero “no la implementamos por a,b,c, bla bla bla …” y cuando se les preguntan por que, suelen decir por que es pesado, no hay tiempo, no es necesario, despues las hacemos, etc. Entonces la moraleja viene a ser “La gente (las personas) no quiere hacer documentos por que es “pesado” para ellos. Entonces es lógico pensar que el proceso (reflejado en las metodologías) no puede ser documentado o llevado a cabo tal cual, en los proyectos,
por que significa mucho trabajo para ellos.”
Sacando conclusiones se puede afirmar que El proceso está escrito (metodología) sin embargo, por lo general, éste no está automatizado. Ahora imaginemos a un usuario definiendo con exactitud, precisión y de manera oportuna sus requerimientos funcionales. Y, que estos requerimientos funcionales puedan ser modelados y diseñados también con exactitud, precisión y de manera oportuna. Es sumamente complicado que las personas hagamos las actividades de procesos de software como si fuéramos máquinas. Las personas somos complejas por naturaleza, tenemos sentimientos,emociones, somos susceptibles, etc. Freud decía que las personas somos 50% buenas y 50% malas, algunas desarrollan más la parte mala o buena, por eso el mundo siempre estará en una lucha constante.
En los procesos software las personas somos “él” proceso. Los modelos de procesos y las metodologías nos ayudan al decirnos “qué” debemos hacer e incluso “cómo” debemos hacerlo pero finalmente somos las personas quienes tenemos la automatización de dichos procesos.
Nadie sabe, por ejemplo, si durante una reunión con usuarios alguno de ellos está triste o apenado, si tiene un problema con su esposa o alguno de sus hijos y eso influirá durante la reunión de toma de requerimientos. Nadie sabe si un programador ha terminado con su enamorada y esto le afecta tanto que ese día, o varios días, no avanzará tal como está programado y después nos dice que no avanzó por x razón, por cualquiera menos por la verdadera causa (en algunas ocasiones lo descrito en el párrafo anterior me ha sucedido, considero que es normal por que soy una persona común y silvestre).
Acotando ante lo descrito “Es sumamente difícil que las personas actuemos como “máquinas” y avancemos según lo planeado.”
Jim Collins en su libro “Las empresas que sobresalen” concluye diciendo que aquellas empresas que han logrado sobresalir durante muchos años, su éxito se ha basado en 3 ejes esenciales: Pensamiento disciplinado, Procesos disciplinados y personas disciplinadas. Si deseamos tener éxito necesitamos una cultura de disciplina, procesos disciplinados y sobre todo personas disciplinadas.
Una de las principales razones por las cuales fracasan la implementación de metodologías es por que no contamos con el
personal apropiado para dicho fin. Por que después de implementada la metodología dichas personas siguen en la institución o no se ha hecho nada por que cambien (si es que tienen cambio).
Una persona disciplinada tiene, entre otras, las siguientes características
fundamentales:
>Capacidad
> Es consecuente (no abandona el proyecto a menos que sea por
una razón esencial)
> Sincero (afronta los hechos no los evita)
> Innovador (propone cambios dentro de los límites del proceso)
> Humildad personal y profesional
> Actitud al cambio
> Es tolerante
La evaluación de las características de disciplina no incluye conocimientos y destrezas por que éstas pueden aprenderse. Existen técnicas para identificar personas disciplinadas.
Muchas veces lo peor no es tener personas disciplinadas sino no hacer nada para que lo sean.
Todo lo anterior escrito esta basado en la experiencia profesional, cursos de capacitación y en el texto de Eric Morán Añazco (MBA. PMP Instuctor en M&T Consulting) que fue mi profesor en el curso de Gestión de proyectos de Software.
Muchos alumnos, estudiantes, colegas, amigos se cuestionan acerca de la norma ISO/IEC 12207 (norma que es para el PERU para el ciclo de vida del software)
La iso 12207 es un modelo de procesos establecido (predeterminado) para gestionar el ciclo de vida del software. Dentro de este modelo de procesos, el ciclo de vida del software es un proceso en el cual se tienen entradas que se transforman en salidas. La siguiente grafica ilustra lo escrito en lineas anteriores:
La norma 12207, como modelo nos indica que tiene procesos y estos procesos (ingenieria de software) tienen tareas que señalan acciones que transforman las entradas (requerimientos) en salidas (producto de software).
Las tareas de la norma ISO/IEC se implementan con las metodologias de gestion de proyectos (PMI), metodologias de desarrollo de software(RUP,XP,MSF). Estas metodologias tienen etapas, fases, planes, entregables, artefactos, cronogramas, etc.
Espero que con esta breve y sencilla descripcion quede mas claro el concepto de la norma ISO/IEC 12207.
El día de hoy cumplo 3 años desarrollando Software en JAVA (Especificación J2EE) y ya Tengo el Rol de Líder de Desarrollo. La experiencia que he adquirido es a nivel de Perú y a nivel internacional; en este post quisiera comentarles acerca de los costos del software Basado en el Libro de Ingeniería del Software de Alfredo Weitzenfeld. (more…)
Empezando el primer post del año 2009, en esta oportunidad quisiera comentarles y que tengan conocimiento de los planes que se necesitan elaborar para gestionar un producto o servicio de software; basándose en normas como el iso 12207 (iso que rige para el PERU y fue recomendado por la ONGEI), Microsoft Solution Framework, CMMI, PMI, RUP, etc.
Planes (no están en orden necesariamente):
Muchas veces, no es necesario elaborar todos estos planes. La elaboración de los planes depende del objetivo del proyecto. Espero que en otros posts, pueda entrar en mas detalle de cada uno de ellos.
Pensando en todos los factores que se desarrollan durante la ejecución de un proyecto de software basados en mi experiencia. He identificado los siguientes:
Esta lista puede crecer más, por que la manera en que se definen las actividades y tareas de cada proceso de desarrollo de software; tienen diferentes actores, diferentes roles y nunca podrán ser iguales.