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.
Hace algunos días tuve que ir a la universidad y me encontré con algunos profesores que todavía se acuerdan de mi, la verdad vi a la profesora que nos enseño introducción a la ingeniería de sistemas, recordé aquellas clases en que nos mandaba a investigar que es la ingeniería de sistemas, que es la computación e informática, la ingeniería de software, ing de computación y sistemas, etc. En este post, lo que voy a comentar es con respecto a la ingeniería de sistemas apoyándome en el libro de Roger Pressman (Ingeniería del software) y transcribiré lo siguiente: ” Tanto para la creación de un sistema de información para asesorar a un departamento de marketing, como el software de control para un robot, requiere de la ingeniería de sistemas”. Un sistema comprende varios componentes: software, hardware, personas, bases de datos, procesos, documentación, etc. La ingeniería de sistemas participa en la traducción de las necesidades del cliente o usuarios en un modelo de sistema que utiliza uno mas de los componentes anteriormente mencionados. Espero contribuir para aclarar todas esas dudas y consultas que frecuentemente ando respondiendo. Y como decíamos en Chile, “Que estén bien!”
Despues de mucho tiempo que me animo a escribir, dado que el calendario del presente año anda muy apretado. En este post, quisiera informar con respecto a la gestion de la configuracion aplicando RUP. Configuracion y gestion del cambio es una de las disciplinas del RUP, el cual realiza flujos de trabajos y tareas especificas. Esta disciplina explica cómo controlar y sincronizar la evolución del conjunto de productos de trabajo que componen un sistema de software. El control ayuda a evitar confusiones costosas y garantiza que los productos de trabajo resultantes no sean conflictivos debido a algún problema de los tipos siguientes:
Cuando dos o más miembros del equipo trabajan por separado en el mismo producto de trabajo, el último en realizar cambios destruye el trabajo del anterior. El problema básico es que si un sistema no da soporte a las actualizaciones simultáneas ello conduce a cambios en serie y ralentiza el proceso de desarrollo. Sin embargo, con las actualizaciones simultáneas, el reto es detectar las actualizaciones que se han producido simultáneamente y resolver las cuestiones de integración cuando se incorporen estos cambios.
Cuando se resuelve un problema en los productos de trabajo compartidos por varios desarrolladores y no se notifica a algunos de ellos del cambio.
La mayoría de programas grandes se desarrollan mediante releases evolutivos. Un release puede ser utilizado por el cliente, mientras otro se está probando y un tercero sigue todavía desarrollándose. Si se detectan problemas en alguna de las versiones, deben propagarse las soluciones entre ellas. Las confusiones pueden conducir a arreglos costosos y a trabajos de rediseño a menos que los cambios tengan un cuidadoso control y gestión.
Las lineas anteriores son una traduccion de la documentacion oficial de la metodologia RUP.
En InfoQ (un portal dedicado al desarrollo de software y mas), Entrevistaron a:
Zeev Suraski, Co-founder of Zend Technologies which oversees PHP advances,
Rob Nicholson, Senior Technical Staff Member, Programming Language Runtimes for IBM,
Derick Rethans, Member of the PHP development team and project leader for eZ components (more…)
Muchas veces me han consultado lo siguiente: “Como puedo saber que aplicacion esta usando un puerto…” pues la respuesta es usar el comando netstat (sobre windows):
Para ejecutarlo, hacemos lo siguiente:
inicio-ejecutar, escribimos cmd y le damos enter. En la consola de windows escribimos:
netstat -n -b
y nos aparecera el resultado deseado.
Esta definicion la tome de: http://www.alegsa.com.ar
en la cual dice:
Definición de DCOM
(Distributed Component Object Model - Modelo de Objetos de Componentes Distribuidos). DCOM es una tecnología de Microsoft que permite desarrollar componentes de software distribuidos sobre múltiples computadoras que se intercomunican. DCOM extiende el modelo COM de Microsoft.
DCOM fue uno de los mayores competidores de CORBA, pero ha sido abandonado en favor del framework .NET.
hoy tuve que resolver un problema entrando a la configuracion de los servicios DCOM, al cual ingrese de la siguiente manera:
inicio, ejecutar y escribir dcomcnfg. Aparecera la siguiente pantalla:
En la realidad empresarial, se utilizan distintas tecnologías de desarrollo de software (componentes de aplicación), por ejemplo:
Un inconveniente común, que puede ser visto en casi todas estas tecnologías, es su incapacidad para interoperar. En otras palabras y citando un ejemplo, si un archivo. NET Remoting tiene que enviar a un componente de Java RMI, hay soluciones que no pueden trabajar todo el tiempo para procesar esos llamados.
A continuación, todos los enumerados anteriormente son las tecnologías a las mejores principios Orientados a Objetos (OOP), en especial usando interfaces para ocultar la implementacion. Esto proporcionará a granel de acoplamiento entre el proveedor y el consumidor, que es muy importante, especialmente en entornos de computación distribuida. Ahora la pregunta es, estas interfaces se resumen suficiente? y quizás Reformular la pregunta, ¿Se puede en tiempo de ejecución Java RMI invocar a una . NET interfaz?
En este sentido, podemos señalar una lista completa de las dudas o algunas que existen en el actual entorno de sistemas e informática. Aquí es donde SOA trae nuevas promesas para las buenas practicas y sus respectivas implementaciones.
Pues el día de hoy, haciendo un poco de lectura se me dio por volver a probar el código que alguna vez se publico en infoq acerca de una comparativa entre las clases StringBuilder vs StringBuffer (el enlace a la noticia es este). En el mencionado articulo se menciona que StringBuilder es mejor en rendimiento (también tiene su tablita de benchamarks de la prueba).El código es este LockTest.java para que realicen la prueba. Pues bien al ejecutar la prueba me di cuenta de algunas cosa que detallare en las lineas siguientes:
> StringBuilder es mas rápido si se ejecuta sobre jdk y no sobre un jre (tremenda fue la sorpresa que me lleve por que mis aplicaciones corren sobre jre, estas aplicaciones las utilizo para distribuir datos).
Las pruebas las realice en Eclipse 3.3.2 he hice lo siguiente:
a mi proyecto le indico que el java build path sea sobre jdk 1.6
el resultado de la ejecucion del codigo es el sgte:
Como vemos, el mencionado StringBuilder se demoro 3312 ms. y StringBuffer 3891 ms.
Ahora en el java build path apuntaremos al jre
Se ejecuta el mismo codigo de LockTest.java y el resultado es:
StringBuilder Demoro mas que StringBuffer. Los invito a realizar pruebas y a retroalimentar este post.
Con Microsoft Office 2007, aparecen nuevos formatos para los archivos de word, excel y power point. En el Office 2007 se puede configurar para que puedas guardar en versiones anteriores. Pero si quieres evitarte la configuración, microsoft tiene disponible una herramienta Microsoft Office Compatibility Pack. Con esta herramientas podrás abrir documentos de office 2007 en todas las versiones anteriores del popular Office. Esta herramienta la puedes descargar de aquí