Aquí además les dejo la presentación nuevamente por si les resulta de interés

>

La incertidumbre al momento de elegir un método de estimación, el poco o ningún historial sobre estimaciones, y el desconocimiento técnico y/o del negocio de los desarrolladores, son los factores que más generan ruido y que pueden llevar a la sobre/sub estimación de las tareas de un proyecto.  Aunque al principio se puede sentir como una bola mágica difícil de comprender, hay ciertos aspectos que se deben de tener en cuenta y que permiten que ésta sea más acertada.

El primer aspecto a tener en cuenta es que entre más cerca del arranque del proyecto esté la estimación, mayor es la imprecisión de la misma, y entre más nos acercamos al final del mismo, más acertado será.  A este fenómeno se le conoce como “cono de incertidumbre” e indica la variabilidad de una estimación a lo largo del mismo.  Se puede identificar en el cono que en la etapa de análisis de prefactibilidad, el error va entre el 45% y el 400%.  Si lo traducimos al ambiente de proyectos de software, la estimación inicial de una tarea puede llevar hasta 4 veces más del tiempo previsto para la misma.

http://cysingsoft.files.wordpress.com/2008/11/cono1.png?w=450

Es importante entonces que si no se tiene otra fuente de estimación para las tareas, se tenga muy presente el margen de error del cono y poder crear el colchón de tiempo necesario para que la tarea pueda ser completada a tiempo y con la calidad esperada.

El siguiente aspecto a tener en cuenta es que el proyecto va a ser realizado por seres humanos, no máquinas.  Parece tonto, pero muchos gerentes olvidan este detalle al momento de estimar, y no tienen en cuenta que un recurso se puede enfermar, tener algún problema personal que los haga ausentar, un trancón, renuncian… en fin, un sinnúmero de riesgos que por lo general se obvian, llevando a tiempos demasiado estrechos y que, cuando ocurren, generan ruido dentro de la ejecución.

Para estos casos, lo ideal es poder tener una estadística de su ocurrencia y agregar dicho valor a la estimación, así como una buena gestión de los riesgos y su respectivo plan de contingencia dentro del proyecto.  En caso de no contar con estas herramientas, se puede comenzar agregando entre un 10% y un 20% del tiempo inicial estimado, y a partir de ahí, ajustar acorde a las necesidades.

Otro aspecto que olvidan muchos gerentes en la estimación, es el know how del negocio que tienen los desarrolladores.  La curva de aprendizaje del negocio es igual para todos cuando ingresan por primera vez sin importar sus capacidades técnicas, y cuando se agrega un recurso nuevo al proyecto, esta curva de aprendizaje se debe de agregar a los estimados de las tareas del mismo.  Es ilógico esperar que un recurso que ingresa nuevo realice en el mismo tiempo una tarea que un recurso del mismo nivel técnico, pero que lleva más tiempo en el proyecto. 

Suele pasar en los proyectos de software que, cuando van atrasados en el cronograma, usan como opción la adición de más personas con un nivel técnico alto para lograr alcanzar el punto de la curva de ejecución donde deberían de estar, pero obvian que, a diferencia de otros tipos de proyectos, en sistemas siempre hay que agregar la curva de aprendizaje del negocio.

Como último aspecto, y no menos importante, durante todas las etapas del proyecto, escuche los comentarios y sugerencias que le hagan su equipo de trabajo, especialmente los más experimentados, con respecto a los tiempos de entrega.  Muchos gerentes creen que con presionar con estos lograrán que se entregue a tiempo, pero solamente aumentan el estrés a nivel interno, al igual que el nivel de deserción.  Si su equipo le está avisando que el tiempo está quedando corto, además de las estrategias de contingencia, le sugiero que comience a hablar con su cliente y lo prepare para el retraso del mismo.

Señor gerente: una planeación estratégica junto con una buena gestión de riesgos y el uso de las estadísticas puede llevar a disminuir la incertidumbre al momento de estimar un proyecto, aunque esta siempre existirá y no se debe despreciar por muy controlado que esté el sistema.  Y por si acaso, mantenga cerca una bola mágica como backup en caso de que todo falle.

Una cosa es cierta: los clientes son el core de cualquier negocio, y son obviamente indispensables para el sostenimiento de cualquier compañía.  Lo que nunca me ha parecido correcto es que sean tratados como "vacas sagradas" a las que hay que cumplirle todos y cada uno de sus caprichos, en el momento y en los tiempos que ellos consideren.  La urgencia de muchos clientes, y el ansia de negocios de muchas compañías, han llevado a los mayores fracasos que he visto en cuanto a proyectos se trata.

Alguna vez en una conversación informal con el profesor de ingeniería de software de mi universidad, me decía que el gran problema de las casas desarrolladoras era el tratar de vender el software como un producto terminado y no como lo que es: un servicio que continúa aún después de la salida a producción.  En ese momento me pareció una total locura y sin sentido, pero con el paso por las empresas me he dado cuenta de que es la realidad: un proyecto de software es un servicio que siempre va evolucionando y cambiando, y no debería de compararse con el proceso para hacer un carro o atender un paciente.

Acá les dejo las quejas que más he escuchado con respecto a los clientes:

1. El cliente ni sabe lo que quiere, y ahora espera que yo sepa.  El 99% de las veces, el cliente sabe que tiene una necesidad que debe de ser cubierta a través de una herramienta tecnológica, pero no tiene claro cómo o con qué.  
2. ¿Me va a cobrar tanto por un "campito" de más/menos?.  Muchos clientes no tienen en claro de que todo es un proceso que tiene movimientos de fondo, y que no es tan sencillo como pensarlo y ya.  ¿Acaso es sencillo agregar un nuevo piso a un edificio? ¿Es pensar y ya hacer una cirugía? Por lo general siempre exigen más cosas que se les olvidó al comienzo del proyecto, pero por el mismo valor y en el mismo tiempo.
3. ¡Ay! pero es que en la otra empresa me cobran menos y lo hacen en menos tiempo. ¿Pero será de mejor calidad? el 100% de las veces que he escuchado esos argumentos, he visto que todo termina en demandas legales por lado y lado.  Todo proceso tiene su tiempo y hay clientes que no logran entenderlo, y mucho más en desarrollo de software por ser un producto intangible.
4. Es que yo leí que eso se hace así. ¿Por qué no lo hacen así? Un cliente que impone camisas de fuerza para el desarrollo de las soluciones, terminan generando ruido y estrés innecesario al proyecto.  Lo natural es que aporte, mas no que imponga.

De nuevo coloco la imagen.  Gracias por todos los aportes que puedan dar.

La ingeniería de pruebas de software se encuentra compuesta por diferentes escenarios que utilizan diferentes contextos, el proceso de automatización de pruebas de software comprende un método independiente de ejecución en el cual la interacción del profesional de pruebas tiene un segundo plano, para empezar a realizar a automatización de pruebas de software se necesitan generar todo un plan de trabajo que tenga claras las actividades, objetivos, estrategias y resultados esperados, generalmente no es posible automatizar todos los niveles de pruebas en un proyecto pero esto depende directamente del conocimiento que posea el grupo de trabajo encargado de la planificación y especificación del plan de pruebas.

La automatización de pruebas de software aporta integración, análisis y estructura de la gestión de defectos, gestión y/o administración de la configuración y parametrización, generación de informes compuestos de métricas, análisis y proyección de los procesos de pruebas.

A continuación relaciono herramientas libres para la automatización de pruebas de software en todos sus niveles:

Nivel 1 (Gestión de pruebas)

- Test link

Herramienta que permite crear y gestionar casos de prueba organizados en planes de pruebas compuestos por los miembros del equipo de tester que se encargará de su posterior ejecución y seguimiento de resultados consolidados en informes, trazabilidad de requisitos de software y prioridades.

Nivel 2 (Gestión de defectos)

- Mantis bug tracker

Gestión y administración de incidencias que permite creación de proyectos, asignación de incidencias, interacción de usuarios y seguimiento a bugs.

Nivel 3 (Pruebas de rendimiento)

- Jmeter

Herramienta para el diseño y ejecución de pruebas de carga, stress, rendimiento sobre Aplicaciones Web.

Nivel 4 (Pruebas de caja blanca)

- Sonar

Análisis sistemático de código a través de la gestión de proyectos, enfoque en el código fuente, pruebas unitarias, métricas de resultados.

Imagenes: http://devsolutions.co/images/testing.png

Acá pongo algunas de las quejas que más he escuchado de los jefes de áreas de desarrollo, si tienen alguna adicional, con gusto será recibida:

1. No tienen en cuenta las "canas" de su equipo: no escuchan las sugerencias de su equipo de desarrollo, o no confía en la experiencia de los mismos.  Tienden a considerar a su equipo de desarrollo como "inferior" o como "terminales brutas" que solamente se deben dedicar a ejecutar.
2. Confunden experiencia con know how del negocio: suelen obviar la curva de aprendizaje de las reglas del negocio, que es diferente al conocimiento técnico de las herramientas de desarrollo.  Ser técnicamente experto no hace al desarrollador experto en las reglas de negocio del proyecto.  Muchos jefes olvidan que esta curva siempre es igual para todos los desarrolladores, y que lo que deben esperar es que la solución al problema si sea en un tiempo menor y con mejor calidad.
3. No tienen capacidad de negociación con el cliente: Le dicen que si a todo lo que pide el cliente sin verificar con su equipo la viabilidad del mismo.  Esto también aplica a que no son capaces de agumentar ante el cliente el porqué de la arquitectura y demás elementos a usar.  Ante su equipo de desarrollo, siempre dan la sensación de estar siempre de parte de las quejas del cliente y junto con la primera queja, hace que el acople de sus integrantes no sea óptimo.
4. Gestión no es presión: Jefes que creen que gestionar es presionar a su equipo a través de amenazas de perder el puesto, o similares.  Creen que usando esta técnica se lograrán mejores resultados, pero la mayoría de las veces lo que se obtiene es que el equipo comience a enviar hojas de vida y ante cualquier oportunidad dejen el proyecto, lo que siempre aumenta el ruido y los problemas en los proyectos.

Acá les dejo la imagen, y en el siguiente post colocaré las quejas más comunes que he escuchado sobre los clientes.

El RUP (Rational Unified Process) en su marco de referencia establece  una serie de practicas con un objetivo definido que consiste en mejorar las practicas o actividades del conjunto de procesos que se llevan a cabo durante el ciclo de vida del software, dichas mejoras nos pueden dar una base que conduzca a ejecutar de mejor manera la actividades del equipo de trabajo.

La industria del software aparentemente posee una "plataforma" que abarca todas sus practicas, sin embargo esta plataforma no puede ser general teniendo en cuenta que existen diferentes metodologías que se ajustan a las necesidades propias de un proyecto, conseguir unificar el equipo de trabajo nos permitirá obtener resultados planificados y definir procesos "comunes" que optimicen la comunicación entre las áreas del proyecto, creando un rendimiento constante y en continuo progreso para tareas, responsabilidades de cada uno de los roles y/o recursos. 

La unificación del proceso de desarrollo de software provee a cada miembro de un rol ciertos parámetros definidos de forma especifica para el proyecto, asegurando que la asignación de recursos sea eficiente a lo largo de todas sus fases.

El proceso unificado mantiene al equipo enfocado en desarrollar un progreso coherente a sus características, con la calidad necesaria para entregar a tiempo un software de confianza.

La buena ejecución de las practicas del RUP genera diferentes beneficios en el desarrollo del software, como disminuir su complejidad mediante un trabajo enfocado a objetivos, interacción interpersonal y frecuente velocidad de reacción en sus diferentes actividades.

En el RUP Los miembros del equipo de trabajo tienen en común:

1. Base de conocimiento
2. Visión de desarrollo del producto
3. Lenguaje unificado de modelado (UML)

Los roles definidos son los siguientes:

1. Analista de documentación (documenting)
2. Programador (Programmer)
3. Administrador del proyecto (Project Manager)
4. Cliente (Customer)
5. Analista y/o ejecutor de pruebas (tester)
6. Revisor  (tracker)

El rol de cada miembro del grupo debe ser definido de acuerdo a su experiencia y capacidades, para cada uno de los roles se establecen objetivos, actividades y/o tareas, interacción y comunicación con otros roles, herramientas y/o recursos a utilizar, misión y visión del rol, y por ultimo el plan de trabajo.

De acuerdo al tipo y tamaño del proyecto se definirá si se requiere contar con todos los roles, en el desarrollo de sistemas de información "complejos" cada rol deberá tener más de una personas, el numero de miembros del rol se establece mediante la cantidad, dificultad y tiempos de ejecución de las actividades.

El compromiso de cada una de las personas pertenecientes a un área es de vital importación en cada una de las fases teniendo en cuenta que el trabajo de cada persona debe estar enfocado a conseguir metas comunes.

Los analistas deben identificar las necesidades y objetivos del cliente, la información que será suministrada al sistema, las funcionalidad del sistema y el rendimiento requerido, ademas de determinar si los requisitos especificados son esenciales para su funcionamiento, de acuerdo a lo anterior el rol de analista es muy importante, debido a que el éxito del proyecto dependerá de una buena especificación de requisitos, para ejecutar sus actividades el analista tiene diferentes metodologías de análisis.

Los programadores deben convertir la especificación del sistema en código fuente ejecutable utilizando uno o más lenguajes de programación, así como herramientas de software de apoyo a la programación. El programador dentro de sus actividades tiene diferentes metas y/o objetivo como lo es reducir la complejidad del software, aumentar la eficiencia en el mantenimiento del software, reducir los tiempos de desarrollo, disminuir el numero de errores encontrados durante el ciclo de vida del proyecto.

El administrador del proyecto deberá entonces tener diferentes fortalezas y cualidades como los son la organización, liderazgo, experiencia, creatividad, toma asertiva de decisiones, además de una comunicación fluida con cada miembro del equipo para analizar problemas particulares, y si es necesario, tomar acciones correctivas.

El cliente es aquella persona responsable de llevar a cabo la evaluación de el buen desempeño del proyecto, por parte de la empresa que contrata el desarrollo, debe estar presente en todas las fases del desarrollo del producto, y realizar todas las actividades que se esperan de él, tales como la aceptación provisional y final del producto, acompañamiento en pruebas y implementación del software.

Los tésters deben utilizar tener habilidades que le permitan definir y ejecutar una metodología que en forma sistemática, organizada y estructurada, les permita detectar y establecer documentación con ideas funcionales e integrales para la corrección de los errores y inconsistencias conceptuales y/o funcionales encontradas en el proceso de desarrollo del sistema.

Los revisores deben tener las habilidades necesarias para descubrir errores en funciones, lógica e implementación en cualquiera de las representaciones del software; verificar que el software bajo revisión cumple con los requisitos, asegurarse que el software ha sido representado de acuerdo al estándar en uso; hacer el proyecto más manejable.

Imagenes: http://gisolutions.us/site/wp-content/uploads/2009/05/rup.jpg

Escribiendo de temas inusuales pero interesantes, inicio este post sobre una norma que presenta de forma clara y definida diferentes conceptos, ordenamientos y estrategias enfocadas a la mejora de cada uno de los procesos del ciclo de vida del software. En su marco de referencia esta norma contiene actividades planteadas de forma específica que abarcan desde el proceso de desarrollo del producto hasta su mantenimiento, pasando por el suministro, implementación y operación funcional. Una de sus grandes ventajas es el orden que plantea para cada ciclo, realizando divisiones por su tipo y modo de ejecución.
Dentro de estas divisiones tenemos los procesos denominados (principales), son definidos con este término por su importancia, generalmente estos proceso son independientes dentro del ciclo de vida del productos, esto no quiere decir que no se encuentren asociados a otros, pero si se trabajan de forma aislada.

El primer proceso principal que interviene con la calidad de Software es el de desarrollo, basado en el análisis de negocio determina el diseño, arquitectura, estructuración y desarrollo de código esencialmente.

El proceso de mantenimiento también es considerado importante dentro de la norma, estas actividades serán vitales para garantizar la calidad del producto, ayuda a que los errores evidenciados en su ambiente final sean solucionadas de fondo, evitando reiteración de errores y consiguiendo un software integral en su funcionamiento de acuerdo al planteamiento del proyecto, esto teniendo en cuenta el levantamiento de información y casos de uso.

La segunda gran división define los procesos como apoyo, ya que estos son "las columnas de nuestro edificio", nos permiten tener fundamentos y bases que posteriormente podrán garantizarnos el éxito y la calidad del software desarrollado.

Inicia con el proceso de (documentación), esta actividad en la que interactúa cliente y proveedor dará como resultado la generación de información objetiva en la que las dos partes deben concluir la misma idea sobre las funcionalidades del sistema.
El segundo proceso de apoyo directamente se relaciona con la calidad del software, en este se deben evaluar los resultados obtenidos de acuerdo a las necesidades del cliente, de acuerdo a los resultados de esta evaluación se establecerán estrategias que permitan determinar el nivel de capacidad funcional y conceptual del sistema.

El proceso de validación que también apoya los procesos principales es un conjunto de actividades relacionadas con las pruebas de software (unitarias, funcionales, integración, validación, aceptación).

La solución de problemas también interviene en el apoyo estructural de los ciclos de vida, este proceso inicia en el análisis de problemas que puede surgir pre o post implementación, el resultado de este debe ser la solución integral de problemas o inconformidades que genere el sistema.

Los procesos internos (organizativos) deben ser trabajados por el proveedor para que sean una ayuda dentro del funcionamiento efectivo y productivo de la organización.

El proceso de mejora tendrá una afectación importante para determinar diferentes conceptos básicos dentro de la calidad del software como lo son la valoración, medición de resultados.

Los recursos humanos son denominados "agentes facilitadores" en esta norma, estos agentes deben tener diferentes habilidades con el fin que cada uno de los procesos puedan ser ejecutados correctamente, estas características pasan por lo personal, profesional y también interviene el trabajo en grupo teniendo como base el liderazgo, el buen uso de las herramientas, el planteamiento de objetivos generales y específicos a conseguir. El planteamiento de ideas innovadoras que puedan concluir en el establecimiento de mejoras es de gran aporte. Los líderes técnicos y funcionales deberán desarrollar la misión, visión, objetivos de cada una de sus áreas para establecer una cultura consiente de la constante búsqueda de la excelencia que debe tener la organización. 

Imagenes: http://www.softexpert.es/images/gestion-ciclo-vida-productos.jpg

En la gestión de un proyecto de software, más allá de las tradicionales medidas de tiempo y costo, deben aplicarse otros criterios para determinar su éxito, todo esto no con el fin de complicar las etapas de desarrollo, por el contrario estos criterios nos ayudaran a definir técnicas y estrategias que puedan ser implementadas de forma tal que no afecte las necesidades del cliente.

En cinco grandes niveles se encuentra compuesto este modelo que poco a poco ha tomado su lugar en empresas que, consientes con los avances tecnológicos, han empezado desde la base a fundamentar y determinar la calidad de sus productos (software).

Los modelos proporcionan una seria de ventajas que los hacen inamovibles después de demostrar sus resultados, proporcionan un marco referencial lo que permite empezar a tener una metodología clara, mucho más metódica y permite que toda una organización empiece a hablar en un mismo lenguaje.

La evaluación de los procesos de software nos permite agrupar y asociar todas las áreas de las que se encuentra compuesta.

El tiempo y costo necesario para alcanzar cada uno de los niveles solo dependerá de la forma en que se implemente el modelo, por lo tanto el primer de los niveles denominado como (nivel inicial) dentro del proceso conceptual del CMMI (MODELO INTEGRADO DE MADUREZ DE LA CAPACIDAD) deberá ser muy bien estudiado para comenzar a trabajarlo, desde este punto se podrán obtener resultados excepcionales realizando un análisis crítico de cada uno de los productos o proyectos, esto último teniendo en cuenta que es poco el porcentaje de empresas que buscan formas de evidenciar sus propios errores.

La distribución de los recursos (humanos y materiales) tienen gran importancia en todo esta etapa de inicio, porque gracias a esta se tendrá claro cuál es el orden y agrupación correcta cuando haya la capacidad de avanzar de nivel.

Inmerso en el segundo nivel (gestionado) se encuentran estrategias de vital importancia en el desarrollo de software con calidad disciplinada, ya que en este punto de la se establecen y siguen políticas organizativas, diferentes normatividades que empezaran por ser una pequeña base que poco a poco se irá fortaleciendo.

Cuando la calidad de software se enfoca exclusivamente en los proyectos su esencia será la planificación, el seguimiento y el control.

El tercer nivel también denominado “definido” hace honor a su nombre ya que plantea todos sus focos en los procesos de la organización, su objetivo general es institucionalizar los procesos como “procesos definidos”, en esta etapa todo el proceso dejara de ser un estándar y pasara a ser único y especial para nuestro tipo de software, la organización debe darle un rumbo de 360º al sentido de su metodología de control de calidad.

En mi concepto no hay una definición clara del cuarto nivel (gestionado cuantitativamente), es increíble lo difícil que puede llegar a realizar una autoevaluación acertada, definir métricas para generar ideas claras de autocrítica es realmente un costoso trabajo, la administración de un  producto consiguiendo llevar estadísticas y metódicas formas cuantitativas de gestionar los procesos del software seria en general su objetivo.

No hay mucho que decir del quinto nivel (En optimización) literalmente es el mantenimiento de todos los niveles anteriores, se debe incrementar y plantear mejoras estructurales que deberán ser revisadas periódicamente.

Todos nos hemos topado con un cliente que es reservado con la información, que pone una y mil trabas para entregar datos de importancia o que sencillamente se niega a actualizar los ambientes. En otras ocasiones, nos hemos encontrado con clientes "expertos" que limitan la arquitectura y la forma de desarrollo, haciendo que sea más complicado el proceso.  En el peor de los casos, nos ha tocado el cliente que quiere ver avances del producto al corto tiempo del arranque, y que tienen expectativas altas con respecto al desarrollo.

¿Qué hacer con estos clientes? ¿Cómo manejarlos o lidiarlos? ¿Se cumple acaso siempre eso de que el cliente tiene la razón? En dos empresas en las que he trabajado, al hacer esta pregunta, obtuve una respuesta que me bajó el espíritu al piso: "Es que detrás de este proyecto vienen muchos más, así que no nos importa quedar mal o cumplir sus caprichos, si eso implica que nos den los otros proyectos".  Al sol de hoy, todavía no comprendo esas decisiones gerenciales en las que prefieren "quemar" a su equipo.

Volviendo al tema inicial, que es el cliente, debemos preguntarnos: ¿Cómo manejar estas situaciones? Si a usted le parece complicado tener que explicarle a su cliente por qué el proyecto está atrasado y cuesta más, debería entonces pensar bien en la posibilidad de explicarle mejor al principio, por qué su licitación es irreal en cuanto a sus expectativas, y darle una propuesta más ajustada a la realidad.  Adicionalmente, la ingieniería de software nos ha enseñado que se debe de pactar con el cliente desde el comienzo qué se va a entregar, pero a su vez, qué nos debe de entregar para que el desarrollo y testeo del mismo sean exitosos.

Más que hablar sobre lo que dicen los libros o la teoría de la gerencia y de la ingeniería de software, te invito a que comentes y pongas tú experiencia sobre el tema, y qué propuestas de solución harías o haz aplicado cuando te enfrentas a un cliente que es difícil de manejar, qué sugerencias le harías o cómo piensas que se debería de tratar esta situación.

El tema, queda abierto a discusión.

La caricatura de la que hablaba, explicaba a grosso modo cómo serían las cosas si los edificios los construyeran los ingenieros de sistemas.  Aunque el usuario nunca pudo explicarle bien al ingeniero qué es lo que quería, se plasmaba algo que siempre se ha padecido en sistemas: preguntarle al cliente qué quiere y este no sabe realmente qué necesita.  Aunque esta es harina de otro costal, lo que más enfatizaba la caricatura era la necesidad de que el cliente entregara cierta documentación sobre lo que se necesita, y es a partir de esta que nace el resto de documentación con la que solemos quebrarnos la cabeza.

El por qué hay que documentar los requerimientos es claro: el cliente cambia de parecer cada que suda, y si no codificamos sobre una línea base, nuestro proyecto será eterno y complejo, pues los clientes siempre querrán agregar nuevas cosas al mismo costo ("¿Qué tanto es poner un botón adicional que llene un campito?") y si no está escrito, es muy probable que vayamos olvidando ciertas cosas.

El prototipo, los diagramas de secuencia, los diagramas de clase, los casos de uso, y todo cuanto artefacto se nos ocurra que hayamos visto en la universidad son los que a nosotros, como desarrolladores, nos darán idea de lo que tendremos que codificar (lo que el cliente quiere).  Es nuestra maqueta, nuestros planos, nuestro esquema.  No imagino a un ingeniero civil comenzar a construir sin tener planos del lugar, o a un cirujano cortar sin haber trazado el mapa de cortes.  Es trabajo de los gerentes de software y los analistas de requisitos hacerle entender al cliente la importancia de estos documentos, y que no es simplemente "tiempo" que mal usamos mientras ellos nos pagan millonadas.

En cuanto a nosotros como desarrolladores, no hay peor pesadilla que tener que hacerle mantenimiento a código ajeno.  Preferimos un harakiri con cuchillo para mantequilla antes que tener que revisar el código de otra persona; ¿por qué? porque muchas veces hacemos las cosas como si fuéramos a estar siempre presentes en el proyecto, y usamos poco o nada de las buenas prácticas de nombrado de variables, codificación, etc.  Una regla de oro en la programación es: Codifica pensando en que vas a ser tú quien va a hacerle mantenimiento a la aplicación, así que escribe el código como te gustaría encontrarlo.  Sé que es suena a cartel de baño, pero es la realidad.  Si todos codificamos con esta regla en mente, nos facilitaremos y le facilitaremos el trabajo a los que vienen detrás.

Mi invitación es hoy a dignificar nuestro trabajo y darle su verdadero valor.  Integremos como parte de nuestra vida diaria todo el sistema de gestión de la calidad y ponerse un verdadero norte como desarrollador y como parte integral de la empresa.  La calidad no es un concepto nuevo, o una moda, y entre más la tengamos presente, mejor será nuestro trabajo y mayor nuestra productividad.  En palabras de mi papá: "No está mal en ser pegador de ladrillos, lo que está mal es no ser EL MEJOR (o al menos intentarlo)".

Hasta una próxima.

Eliana

 Intento mostrar con este artículo algo superficial de cómo es el mundo del aseguramiento de calidad a nivel empresarial.

Hace ya algún tiempo vi que HP estaba empezando a ofrecer un nuevo servicio: HP Testing as a Service. como concepto es algo que no es nuevo pero puede serlo para nuestro país.

Normalmente las empresas que se dedican a ofrecer servicio de testing lo hacen en modalidad de Outsourcing o Body Shopping cobran basado en lo que pueda costar los recursos que se asignen (personas o herramientas)  o hasta la metodología que se esté usando (puede cobrarse un testing manual o puede cobrarse la automatización de las pruebas) y con esto formar las bases para las estimaciones en tiempo y dinero en el proyecto.

Por otra parte, conocemos que entre más temprano se detecte un fallo es menos costoso para el proyecto, atribuimos a veces que los gerentes de proyectos de software no conocen este tema y deciden dejar las etapas de pruebas para el final, pero tomando en cuenta este modelo que se opera en las empresas de testing, es posible que la falla se origine aquí.

Como Project manager se deben cuidar los desfases tanto en tiempo, costo y recursos, con el conocimiento de que un recurso de pruebas es costoso se tomará mayor cuidado en qué punto del proyecto entrará a operar, así una de las opciones para esto es empezar cuando el desarrollo esté terminado.

El modelo que está ofreciendo HP es conocido como Testing as a Service, no es creado por ellos pues como concepto existe desde hace ya algún tiempo (no tengo fecha de referencia) y de la misma forma ya hay empresas internacionales que operan con él.

Como Objetivo TaaS busca que las organizaciones se centren en su core (como todas las empresas de outsourcing) la diferencia radica en que el servicio que se ofrezca sea por demanda y además de esto reduciendo al máximo los costos de los recursos asignados, de esta forma TaaS opera algo así:

• La forma de ingresos está basada más en la cantidad de casos de pruebas que en el costo del recurso, de esta forma con lo que podría costar un recurso en un mes, se podrían hacer los suficientes casos de pruebas que garanticen una cobertura considerable. Se establecen valores fijos para cada servicio ofrecido o el tipo de test que se requiera (funcionales o no funcionales)
• Se cuentan con SLAs (Acuerdos de niveles de Servicios / Service Level Agreements) establecidos con los que se pueden tomar decisiones de estimación o decisiones contractuales.
• El tiempo es un factor importante,  definen un claro y estricto cronograma de trabajo
• No es relevante para el cliente las herramientas ni la metodología que se use, como estas empresas ofrecen rapidez y cumplimento en cronograma, es posible que para los casos de pruebas que se envíen estén utilizando técnicas automatizadas o estén varios recursos personas asignados haciendo manualmente las pruebas, para el cliente sería transparente. 

De la forma como operan estas empresas ya es más cercano que se implementen mecanismos de aseguramiento de calidad desde etapas muy tempranas en un proyecto.

Un caso exitoso es la empresa uTest.  Fue fundada en el 2007 y trabaja con este modelo de forma virtual, ha creado una aplicación web a través de la cual Testers de todo el mudo pueden unirse y de esta forma van incrementando su personal. Las empresas que quieren contratar con ellos, emiten su solicitud y uTest publica la necesidad de realizar un tipo de pruebas que se debe entregar en una fecha límite (tiempo establecido), los testers que deseen participar en el proyecto lo notifican y de esta forma un producto puede ser probado por muchas personas (recursos asignados) de diferentes países con diferente experiencia. A estas personas se les paga por bug registrado y aceptado ya que es posible que ya un error o falla haya sido registrado por otra persona. (Costo del servicio).

Este es un modelo interesante, pues cualquier persona puede realizar la solicitud de ingreso y cuando se sienta preparado para participar, notificarlo (si desea participar en él aconsejo empezar por los proyectos de traducción mientras se adquiere la confianza necesaria para otros proyectos)

Estuve leyendo una info sobre Calidad de Software recorde sobre los enfoques de Calidad, ISO/IEC ha definido tres modelos relacionados de calidad de productos software (la calidad interna, la calidad externa, y la calidad en el empleo) (ISO9126-01) y un conjunto de partes relacionadas (ISO14598-98); de ahi nace dos enfoques de Calidad como son:

• Calidad del Producto
• Calidad del Proceso

No me voy a exterder con definiciones pero si conceptualizare para tener una idea general sobre los tipos de enfoques.

Enfoque hacia el Producto

Aqui se ve la importancia del rol del Ingeniero de Software para comenzar asi un desarrollo de un optimo producto.

Enfoque hacia el Proceso



Nazly Borrero Vasquez

http://nazlyborrero.blogspot.com/

La calidad de software, verifica el cumplimiento de todas las normas y estándares de calidad establecidas internacionalmente para un óptimo funcionamiento, fiabilidad, seguridad. Para así cuando este esté en producción no tenga fallas en su funcionalidad interno y externo; y así no tener problemas graves como inconsistencias en datos, tiempos, etc.

La Ingeniería de Software es la forma de producir, crear un software, donde  estos  son llevados por los ingenieros donde utilizan herramientas  para dar soluciones a los problemas creados para el desarrollo, como también para distribuir todos los recursos necesarios para llevarlo a cabo y así sacar a producción un software que este dentro de los estándares internacionales de calidad.

Para tener una muy buena ingeniería de software hay que tener en cuenta que en su proceso debe llevarse unas secuencias y  así obtener un software de calidad, como son el análisis, diseño, pruebas, implementación, producción.

Me gustaría hablar un poco de las personas que se dedican a realizar la actividad de pruebas y debo empezar por algo que me parece un poco injusto,  en el mundo del desarrollo o en el mundo del software (como lo prefieran llamar) ser tester es considerado a veces como un trabajo insignificante, en el recorrido de mi experiencia académica y laboral he escuchado varias veces decir frases como: “el tester es un programador frustrado”  o “el tester es el ingeniero que no pegó en nada” comentaré a continuación algunas de las características que tienen (o deben tener) las personas que se dedican a esta actividad. Y espero con esto cambiar un poco ese pensamiento

Como habilidad principal, debe ser una persona con gran capacidad de análisis su trabajo no es sólo probar que el software funciona, además es hallar errores o defectos en el software, también debe involucrarse con el negocio y de esta forma hallar ambigüedades o contradicciones en las reglas de negocios, generando posibles escenarios en los que pudiera ser funcional el producto de software y en los que pudiera fallar. En ocasiones es posible que analice fragmentos de códigos para dar una justificación o poder sugerir solución (en el caso que se le permita) y en este sentido deberá estar en la capacidad de entender el lenguaje de programación y más aún, entender la lógica de la persona que lo desarrolló (algo que no es sencillo).

En contraste con lo anterior y siendo una característica común en las personas que les gusta el tema de tecnología, deben tener “hambre” por el conocimiento, tener un sentido de la curiosidad y un poco de creatividad.

También debe ser una persona que tenga habilidades de comunicación, recordemos que los “testers” están enfrentados tanto a diálogos con arquitectos, desarrolladores, programadores, DBA’s, etc. como a líderes de proyectos funcionales o técnicos, gerentes de proyectos y (seguramente) hasta usuarios finales (en los casos en que guíen o apoyen las pruebas de aceptación de usuario UAT). Al estar relacionados con varios roles dentro de un proyecto debo decir que el ser objetivo es algo que cuenta mucho, también se ha visto que en los proyectos se arman “bandos” algunos que están en pro de algo y otros en contra, unos defienden y otros atacan (no sé las razones pero es algo inevitable) en este caso, la objetividad es nuestra arma.

Cada proyecto trabajado por un tester es un proyecto del cual aprende temas o técnicas que pueden ser usadas en proyectos futuros. El tester debe ser capaz de ser humilde (en lo que sabe) y no tomar estos conocimientos como los únicos y absolutos, recordemos que cada proyecto es diferente y es debido a esto que no podemos abordar los temas de la misma forma que lo hemos hecho anteriormente. 

En este punto debo confesar que soy un amante a la planeación y personalmente creo que es importante que se tenga la habilidad de planear las actividades que se van a realizar, así como las herramientas que se van a utilizar y en lo posible las características de los casos de pruebas que se tomarán en cuenta. Normalmente debemos definir cuales serán nuestros criterios de aceptación o rechazo del producto (con ayuda del que esté liderando el proyecto) el alcance que se tendrá, módulos o ítems a cubrir en las pruebas y el tiempo estimado en que se realizará. Esto nos ayuda para ir realizando análisis de los casos cubiertos, ir monitoreando las acciones y realizando una retroalimentación al equipo y también para tomar decisiones en las actividades futuras, debemos ser consiente que el plan no es estático y puede cambiar en el transcurso del proyecto.

Así como me gusta mucho la planeación también me gusta crear casos de pruebas derivados de los resultado que obtengo ejecutando algún otro o crear casos  basado en sospechas que pueda tener en algún punto del producto analizado. Tal vez esto que esté diciendo pueda estar en contra a lo que dije anteriormente pero considero que ser tester no es solo ejecutar un caso y comparar el resultado con algún resultado esperado, debemos ir más allá y debemos saber equilibrar qué tantos casos podemos crear derivados de otros para que no afecte en gran medida nuestro tiempo estimado y pueda generar desfases grandes en el proyecto.

Por último me gustaría comentar varias cosas en calidad de consejos:

Consejo 1: Preguntarse siempre “que tal si…”  lo escuché en una conferencia hace poco relacionada con temas de emprendimiento, pero creo que aplica completamente en esta actividad y ayudará mucho a las personas que están empezando con el tema, no recuerdo quien la dijo (Perdón por no citar) si alguien la ha escuchado, espero que me ayude con la cita 

Consejo 2: Eliminar la frase “esto está malo” o reducirla al máximo, esta frase genera confrontaciones entre personas y se crea un mal clima. Ser más diplomático en ese sentido ayudará a conservar las relaciones y la colaboración entre los integrantes

Consejo 3: No se debería justificar un fallo sólo porque se piensa que lo es (pecamos mucho en este aspecto), si se identifica un fallo es porque somos capaces de justificar que no está de acuerdo con un requisito, regla de negocio o ley y por ende degrada la calidad que percibe el cliente.

Consejo 4: El tester no es el responsable de la calidad, él no la crea ni la quita, sólo la evidencia. La calidad viene de la personas que desarrollan el producto y debemos trabajar junto a ellos  (no en contra) para poder sacar como resultado un producto de calidad para el cliente, recordemos que somos un equipo y no estamos jugando unos contra otros.

Trataré de recomendar algún contenido sobre el tema cada vez que escriba, por ahora recomendaré un libro. Fue el que me recomendaron cuando quería involucrarme en esta actividad.

Lesson Learned in Software Testing (Cem Kaner, James Bach, Bret Pettichord)

Imagen tomada de: http://www.competence.co.in/Certifications.html