Muchos bichos, pocas balas

19 Ene

Lanzar una aplicación software a entorno de producción sin ser probada es como poner a vender una torta sin ni siquiera haberla probado al menos una vez.

Ahora bien, a diferencia de este ejemplo culinario, probar una torta es mucho mas sencillo (y rico!) que probar una aplicación. Tenemos probablemente cientos de escenarios posibles para validar. Por ello, el primer gran consejo es priorizar los casos de prueba a ejecutar. Ésto basicamente deberiamos realizarlo por dos motivos:

  1. No sobre eltiempo para poder testear todo.
  2. No conviene testear todo, ya que aqui tambien podemos aplicar la ley de Pareto: el 20% de los casos de prueba representa el 80% de los bugs de importancia que deberemos detectar.

Viendo estos dos puntos, entramos en una disyuntiva importante: ¿cuales son los casos de prueba que caen dentro del 20%? o lo que es lo mismo ¿que nos conviene testear?

Para responder esta pregunta se han definido varios tipos de heuristicas, las cuales buscan resumir en un grupo de palabras aquellas caracteristicas que deberemos fijar para priorizar la funcionalidad a testear.

Así, proponemos un ejercicio que parte de lo siguiente: en cada una de las siguientes categorias, asignar a cada funcionalidad del sistema, una puntuación según el grado de importancia de la misma respecto a la categoria. Las puntuaciones son:

  1. Poco importante que funcione perfectamente.
  2. Importante que funcione perfectamente.
  3. Muy importante que funcione perfectamente.

Como categorias a considerar, proponemos:

Negocio
Que tan importante es para el negocio.

Críticas tecnicamente
Segun que tan criticas son las funciones desde el punto de vista de los aspectos tecnicos que involucra.

Frecuencia de Uso
Que tan importante es, segun la frecuencia de uso.

Intensiva en recursos
Segun que tan demandante de recursos sea la funcionalidad.

Obligatorias
Segun que tan obligatorias son las funcionalidades pedidas por los interesados.

Aspectos legales
Segun si haya requerimiento legales que deba respetar.

La siguiente tabla refleja este análisis para unas funcionalidades tipicas. Se colocan las mismas y por cada una se define la importancia según las categorias anteriores. Obtenido el total de puntos por funcionalidad, nos resta ordenarlas por importancia y concentrarnos en testear aquellas que agrupen el 70-80% de importancia.


Como dato no menor, podemos obviamente agregar mas categorias para hacer este análisis mas exhaustivo.

Por ahora nada mas amigos, me voy con una sonrisa.

Nos vemos, Gastón

Post basado en: http://searchsoftwarequality.techtarget.com/answer/Prioritizing-software-testing-on-little-time

Anuncios

El nacimiento de un proyecto

4 Ene

Buenas, feliz 2011 para todos!!. Para arrancar este nuevo año con la mejor de las ondas, les traigo una cuota de humor que espero que les arranque alguna que otra risa o al menos una reflexión jeje. Alguna vez se preguntaron como nace un proyecto en una empresa? bueno, aqui les va una posible respuesta:

Programador al responsable técnico:

“Es imposible que nosotros podamos hacer este proyecto. Supone cambios de diseño y nadie en nuestro equipo sabe como está hecho el sistema, además nadie en nuestra compañía conoce el lenguaje con el que se ha escrito el programa. Así que, si asignamos a alguien a trabajar en él, no podrá hacer nada. Si me preguntas mi opinión personal te diré que nuestra compañía nunca debería de realizar este tipo de proyectos “.

Responsable técnico a Project Manager:

“Este proyecto implica un cambio de diseño. En la actualidad no contamos con gente con experiencia en este tipo de trabajo. También el lenguaje es desconocido para nosotros, así que tendremos que organizar algún tipo de formación y un periodo de adecuación si se aborda el proyecto. En mi opinión, debemos evitar aceptar este proyecto. “

Project Manager a Director de Informática:

“Este proyecto implica un cambio de diseño en el sistema y no tenemos mucha experiencia en esa área. Tampoco tenemos mucho personal capacitado en este lenguaje. Creo que podemos aceptar este proyecto pero deberíamos pedir un poco de más tiempo. “

Director de informática a Directivo senior:

“Este proyecto consiste en una reingeniería de la aplicación. Tenemos algunas personas que han trabajado en esta área y algunos que conocen el lenguaje y que pueden entrenar a otras personas. En mi opinión, podemos aceptar este proyecto pero con precaución. “

Directivo senior a Director General:

“Este proyecto va a demostrar a la industria nuestras capacidades en el rediseño de un sistema complejo. Tenemos todos los conocimientos necesarios y las personas necesarias para ejecutar este proyecto con éxito. Algunos de nuestros técnicos ya han empezado a dar formación en este ámbito a otras personas. Creo que no debemos dejar escapar este proyecto bajo ninguna circunstancia. “

Director General al Cliente:

“Este es el tipo de proyectos en los que nuestra compañía se especializa. Hemos realizado muchos proyectos de la misma naturaleza en grandes clientes. Confía en mí cuando digo que no podrías estar en mejores manos. Te doy mi palabra que podemos realizar este proyecto con éxito y en el marco de tiempo dado.

Nos vemos, Gastón!.

Palabras responsables

3 Dic

La comunicación es una de las disciplinas mas importantes a gestionar durante un proyecto (el PMBok posee todo un capítulo para este tema) . En un nuevo emprendimiento existen usuarios, equipos, líderes de equipo, directores de proyectos, sponsores y otros interesados que tienen cada uno sus expectativas y objetivos que esperan que sean cumplidos.

Es ahi entonces, cuando todos los actores anteriores, cada uno en el rol que le corresponde, comienzan a interactuar para empezar a hacer rodar la pelota y lograr alcanzar el éxito cuando suene el silbato final.

Pero no es fácil, el proceso de la comunicación es complejo pues uno como persona (antes que como sponsor, lider o parte de un equipo) ya tiene una tendencia a comunicar las cosas en forma ineficiente. Causas de esto son muchas: intereses, influencias, sentimientos, conflictos, prejuicios, etc.

Puntualmente, dentro de un equipo de trabajo, una vez definidos los canales de comunicacion entre todos los miembros, lo que debe fluir por ellos es información que sea válida, clara y útil para el desarrollo y conclusión de las diferentes actividades. Debemos elaborar y adueñarnos de la necesidad de comunicar con responsabilidad.

Les dejo una anécdota de Socrates que grafica este punto de la responsabilidad e invita a aplicarla en nuestros proyectos profesionales, y nuestro proyecto mayor: nuestra vida.

En la antigua Grecia, Sócrates fue famoso por su sabiduría y por el gran respeto que profesaba a todos. Un día un conocido se encontró con el gran filosofo y le dijo:
¿Sabes lo que escuche acerca de tu amigo?.
Espera un minuto -replico Sócrates-. Antes de decirme nada quisiera que pasaras un pequeño examen. Yo lo llamo el examen del triple filtro.
¿Triple filtro?
Correcto -continuó Sócrates-. Antes de que me hables sobre mi amigo, puede ser una buena idea filtrar tres veces lo que vas a decir. Es por eso que lo llamo el examen del triple filtro. El primer filtro es la verdad.
¿Estás absolutamente seguro de que lo que vas a decirme es cierto?
No -dijo el hombre-, realmente solo escuché sobre eso y….
Bien -dijo Sócrates-. Entonces realmente no sabes si es cierto o no.
Ahora permíteme aplicar el segundo filtro, el filtro de la bondad. ¿Es algo bueno lo que vas a decirme de mi amigo?
No, por el contrario…
Entonces, deseas decirme algo malo sobre él, pero no estás seguro de que sea cierto. Pero podría querer escucharlo porque queda un filtro: el filtro de la utilidad. ¿Me servirá de algo saber lo que vas a decirme de mi amigo?
No, la verdad que no.
Bien -concluyó Sócrates-, si lo que deseas decirme no es cierto, ni bueno, e incluso no me es útil, ¿para qué querría yo saberlo? !!!

Saludos, Gastón

Excusas…no!

24 Nov

El equipo es uno de los pilares fundamentales sobre los cuales se sustenta el éxito o fracaso de un proyecto. El óptimo encaje de cada pieza es un objetivo que todo PM busca conseguir pero que no siempre puede lograr. Motivos, sobran, lo cierto es que antes de poder optimizar algo deberemos lograr que funcione y para que funcione deberemos entender la dinámica por la cual atraviesa un equipo. El PMBok nos aporta luz respeto a este punto. En el capítulo 9 nos dice:

Segun una teoria, existen cincos etapas de desarrollo que los equipos pueden atravesar. Normalmente, estas etapas se presentan en orden. Sin embargo es frecuente que un equipo quede atascado en una etapa particular o retroceda a una etapa anterior. Ademas, en caso de proyectos cuyos miembros del equipo han trabajado juntos en el pasado, es posible que se salte una de las etapas.

  • Formación: El equipo se reúne y se informa acerca del proyecto y de cuáles son sus roles y responsabilidades formales. Los miembros actuan de manera independiente y no suficientemente abierta.
  • Turbulencia: El equipo comienza a abordar el trabajo del proyecto, las decisiones técnicas y el enfoque de dirección de Proyectos. Si no hay colaboración, el ambiente puede tornarse destructivo.
  • Normalización: Los miembros del equipo comienzan a trabajar en conjunto y adaptan sus comportamientos y hábitos de trabajo para apoyar al equipo. Los miembros comienzan a confiar uno en otros.
  • Desempeño: El equipo funciona como una unidad bien organizada. Enfrentan los problemas con eficacia y sin complicaciones.
  • Disolución: El equipo completa el trabajo y finaliza el proyecto.

Una vez formado el equipo, nuestro norte sera poder alcanzar rápidamente el estado de desempeño, donde todo fluirá de la forma mas óptima posible hasta que alcancemos el punto final exitoso donde debamos disolver el equipo.

Ahora bien, este nivel de desempeño es sinónimo de eficiencia y esta eficiencia se consigue con esfuerzo, esfuerzo para entregar día a día lo mejor de cada uno. Sabiendo que hay que dar una dura batalla, ¡quien nos impulsa a caminar ese largo camino? ¿quien nos mueve a empujar y empujar? ¿quien es el combustible de nuestra búsqueda constante de hacer las cosas mejor?. Mi respuesta esta en la motivacion. La motivacion son los estímulos que mueven a la persona a realizar determinadas acciones y persistir en ellas para su culminación (Wikipedia). Es el combustible que nos mueve a seguir estirando el brazo para poder alcanzar el escurridizo objetivo.

Este combustible, necesario para que una persona o un equipo alcance su nivel máximo de desempeño, puede nacer en diferentes necesidades: dinero, calidad de vida, bienes materiales, logro profesional, honor, ego, etc.

Pero, como todo combustible, muchas veces se nos acaba cuando vemos que las cosas son mas complicadas que lo que parecian, mas dificiles de lo que las habiamos planificado, mas lejano todo de lo que pensabamos tenerlo…y ahi me vienen a la mente dos pensamientos recurrentes que suelen darse y que muy bien el video que les dejo grafica: o quienes logran el éxito es porque siempre tuvieron todo fácil o uno está poniendo excusas para no levantarse y continuar. ¿Con cual se quedán ustedes?.

Saludos, Gastón.

Creepeando el Scope

19 Nov

Un proyecto es un viaje que nos invita a recorrer diferentes etapas durante la producción de un producto o servicio y la correspondiente gestión de la producción. Durante estos caminos, deberemos cuidarnos de amenazas que pueden surgir. Para esto, deberemos primero aprender a reconocerlas y luego a disponer de un grupo de herramientas que nos permitan reaccionar y gestionar dichos riesgos.

Los proyectos, idealmente, comienzan por deseos de un grupo de entusiastas sponsores y usuarios en realizar o impulsar un grupo de actividades que conduzcan a lograr unos objetivos que permitan satisfacer alguna necesidad.

La base sobre la cual se sustenta un proyecto es el denominado Alcance del Proyecto (Project Scope). Esto es, ¿que vamos a hacer? ¿cuales son los objetivos que esperamos lograr con este proyecto?. Esta lista de objetivos deberia ajustarse para responder una nueva pregunta: ¿esto que QUEREMOS hacer, PODREMOS hacerlo teniendo en cuentas las restricciones de COSTOS, TIEMPOS, RECURSOS que tenemos impuestas?. Los requerimientos para los cuales me contesté que NO, entonces deberiamos sacarlos del alcance planificado.

Restricciones, bien bien, alli comienza el dilema. Al comenzar a definir el alcance, solemos definir una lista de los requerimientos (funcionales, no funcionales, etc) que el proyecto debe satisfacer. Este listado se confecciona y acuerda por un grupo de interesados entre los cuales estan los usuarios, sponsores y por otro lado el Director de Proyecto y el equipo técnico. Cuando este grupo de interesados define el alcance de forma sesgada, éste sufre consecuencias que afectarán el exito del proyecto. Estas consecuencias podemos resumirlas en las siguientes:

  • Requerimientos “Flacos”: las especificaciones no quedan claras en cuanto a que debe hacer el proyecto. Los tiempos avanzan, el equipo avanza cumpliendo lo que tiene claro pero dejando sin hacer los huecos funcionales que no fueron definidos. Aqui se avanza pero sin tener una clara perspectiva de que se esperar lograr.
  • Requerimientos “Gordos”: las especificaciones son excesivamente detalladas o contemplan aspectos extras que exceden la descripcion respecto a una verdadera necesidad del proyecto.
  • Requerimientos Dinamicos: Las especificaciones cambian constantemente sin que se pueda estabilizar la lista de requerimientos inicial y el detalle de cada uno de estos.
  • Requerimientos Innecesarios: Se incorporan requerimientos en pos de dotar al sistema de funcionalidades innecesarias para el proyecto. Aqui se busca embellecer los requerimientos con features que el cliente no desea.

Estos cuatro puntos representan posibles riesgos que afectan a la etapa de definición de requisitos y planificacion del alcance.

El punto 3 de las anomalias referidas a los requerimientos, se denomina Scope Creep. Este termino se refiere a los cambios descontrolados en el alcance de un proyecto que ya ha comenzado. El SC conduce no solo al retraso del proyecto sino tambien nos hace incurrir en mayores costos, a degradar la calidad en pos de poder cumplir con todo, y al desgano del equipo cuando las cosas no salen como fueron planeadas. El SC muchas veces es producto de una excesivo entusiasmo (o viveza) de los usuarios y sponsores que piden mas de lo que se acordó esperando que los proveedores puedan hacer mas de lo que dijeron que podrian.

El poder controlar el SC a veces viene con la experiencia que pueda tener un PM, pero no obstante, pudiendo detectar esta situacion, cualquier PM podria, al menos identificar que está ante ese problema y disponer de algunos tips para ponerse en guardia frente a la amenaza. Algunos de estos tips son:

De listado de requerimientos

1) Definir una linea base de requerimientos. Realizar un analisis completo de los requerimientos. Esto es importante ya que contra este analisis se evaluará si estamos corrompiendo el alcance o no. Aqui es importante definir una lista bastante estable de funcionalidades y cada una de ellas con el peso exacto (ni flacas ni gordas). Este documento sirve al PM para saber la cantidad de requerimientos acordados, la frecuencia con la cual aparecen los nuevos cambios y poder evaluar el impacto si se considera aceptarlos.

Del control de los requerimientos

2) Determinar un control de cambios solido. Definir un mecanismo para controlar (ojo, controlar no es negar por negar) los cambios que se desean realizar sobre la lista del punto anterior. Ese mecanismo permitirá tener una única puerta de entrada para los cambios. Dependiendo de los proyectos esta puerta puede ser giratoria o blindada (;-).

3) Asociar costos con cada cambio propuesto. Muchas veces los clientes piden cosas porque creen que no representan costo alguno. Si podemos darles a conocer, por cada cambio solicitado, cual es el costo del mismo (en materia de retraso del proyecto, inversion de dinero, etc), los clientes pensarán dos o mas veces antes de solicitar cambiar algo. En resumen, si logramos demostrarles como el cambio solicitado altera las restricciones impuestas o aprobadas por ellos, podrán analizar mas claramente si dicho cambio se justifica o no.

4) Encolar (no negar) los requerimientos. Puede que el cliente quiera igualmente incurrir en costos por el cambio que desea. Aqui, es mas conveniente recibir el cambio, priorizarlo y encolarlo segun la prioridad en la lista de requerimientos a implementar, habiendo antes el cliente entendido que el proyecto trabaja en fases y que pronto vendrá la correspondiente fase donde se desarrolle ese requerimiento.

5) No sea un “Yes man”. La importancia de decirle que “si” a un cliente es critica cuando estamos vendiendo un proyecto. Una vez acordado el inicio y comenzada la fase de desarrollo si continuamos con esa filosofia de decirle que “si” a todo, aunque agreguemos features al producto, estamos afectando a otras variables que intervienen en la ejecucion del proyecto, como son los tiempos y los costos. Aqui entonces, o no modificamos nada (o lo minimo y necesario) o el cliente acepta las consecuencias y aprueba las consecuencias.

6) Saber cuando hacer sonar la alarma: Es importante tambien notificar a managers y gerentes con informacion clave (que hace el cambio, costos, beneficios e impacto en el schedule). El objetivo aqui es lograr el conocimiento de los sponsors del proyecto para trabajar en definir si se acepta el cambio o no.

Del acuerdo de los requerimientos

7) Obtener el acuerdo por parte de los clientes. De alguna forma es importante obtener el consenso de los clientes para poder luego considerar el diseño e implementación de un requerimiento. Pero tambien es cierto que dichos clientes son reacios a colocar alguna firma que cierre la especificacion en un instante determinado ya que tampoco ellos pueden estar seguros de lo que estan solicitando. Para ello entonces deberemos buscar posibilidades para lograr dicho acuerdo sin necesidad de que nuestro cliente sienta que lo estamos hostigando para que nos cierre algo.

De la Gestion de los requerimientos

8 ) Implementar una buena herramienta de gestion de requerimientos. Estas herramientas ademas de permitir la gestion de la linea base de un proyecto, permiten que otros interesados (desarrolladores, analistas) accedan a los requerimientos y puedan consultarlos y analizarlos.

9) Estar siempre atento a la posibilidad de Scope Creep. Mantenerse alerta ante cada posibilidad de un cambio o agregado de feature. Estos son los tipicos eventos que pueden conducir al scope creep. Aunque uno sea el mejor project manager, puede que no pueda evitar el scope creep, simplemente porque existen condiciones que no pueden manejarse con los tips anteriores (o con ningun tip!). Ante esas situaciones tenemos o la posibilidad de irnos a otro proyecto o de continuar buscando minimizar los impactos negativos. El costado positivo de un proyecto con scope creep es que el PM aprende dia a dia como lidiar con los requerimientos fuera de control. Las lecciones aprendidas que pueda extraer de esos proyectos seran de muchisimo utilidad en futuros proyectos.

10) Considerar prácticas de Proyectos agiles. Los proyectos agiles permiten reducir el impacto del scope creep a partir del concepto de iteracion.

  • Proyectos tipicos: Especificacion funcional detallada al inicio, grandes documentos de requerimientos, cronograma y entregas cada 3 meses, 6 meses, etc.
  • Proyectos agiles : Especificacion funcional general  al inicio, especificacion detallada por iteracion, documentos mas pequeños, entregas cada 2 semanas.

Los proyectos agiles disminuyen la ansiedad del usuario ya que en cada iteracion se van entregando pequeñas porciones operativas del producto, las especificaciones son mas pequeñas y por lo tanto mas facil el acuerdo de que debe hacerse y en las ventanas de tiempo (las iteraciones) es factible freezar los requerimientos para que el cliente no los modifique.

En conclusion, los proyectos se planifican para cumplir con un alcance determinado. Si este alcance no esta estable y debe crecer o modificarse de forma frecuente, el no considerar el impacto en las restricciones iniciales conducirá al proyecto a resultados no deseados por los diferentes interesados.

Saludos,  Gastón

Basado en: http://www.gatherspace.com/static/scope_creep.html

Complejidad Ciclomática: la calidad está en las raices

19 Oct

Para poder afirmar que un producto o software es de calidad, deberemos contemplarlo desde muchas perspectivas. No basta solo decir que haga lo que deba hacer, que no se cuelgue y que no corrompa los datos. Tampoco basta considerar la elegancia de la interfaz, la velocidad de sus operaciones, etc. etc..

Calidad implica considerar muchas variables, y entre ellas, una no menor y muchas veces descuidada por no ser visible para el usuario; una variable que es la raiz que sustenta todo un producto sofware: el código.

En los años 60/70, esta pregunta genero diferentes ramas de investigacion. La suposicion inicial fue que deberiamos poder medir de alguna manera el codigo y asi producir un valor numerico, con el cual podamos hacer comparaciones y determinar el porque de valores grandes o pequeños. Esta investigacion resulto en una nueva rama de la ingeniera del software destinada a estudiar las llamadas metricas de software.

La primera y mas comun medida utilizada para analizar codigos de diferentes productos fueron las LOC (lines of code). Éstas son un reflejo del tamaño del producto. El objetivo inicial fue suponer que a mayor cantidad de lineas de codigo, el software era mas complejo. Esta metrica fue rapidamente debatida puesto que tiene muchas desventajas:

1. Los comentarios, saltos de lineas, codigo tabulado, etc. contabilizan en la sumatoria de lineas de codigo. Conclusion: un codigo muy documento puede tener muchas lineas pero no necesariamente indica que sea complejo.

2. Segun el lenguaje de programacion, hacer lo mismo puede tener una determinada longitud en un lenguaje que en otro. Conclusion: un codigo desarrollado en un lenguaje puede suponerse complejo cuando en realidad no lo es.

3. Existen lineas de codigo que son mas faciles que otra. No es lo mismo incrementar un valor que hacer un loop. Conclusion: Si nuestro codigo tiene miles de linea de incremento de valor puede pensarse mas complejo que otro producto que tiene una sola linea de loop.

A partir de los puntos anteriores, vemos entonces que la real calidad del codigo esta vinculada con la capacidad de los programadores de entender dicho codigo. Escribir codigo complejo probablemente conduza a codigo de menor calidad. Si entendemos el codigo podremos entonces mas facil determinar si funciona o si tiene bugs.

En 1976,  Thomas J. McCabe dio con una metrica a la que llamo Complejidad Ciclomatica (CC). Esta describe la complejidad del flujo de control de un programa. Es una representacion numerica de un flowchart: cuanto mas cajas de decision haya, mas complejo será el control del programa. Actualmente, la metrica CC es un muy buen indicador de la calidad de un programa.

McCabe no solo muestra que los programas con bajas CC son mas confiables, sino que tambien muestra como calcular el CC total combinando las CC de rutinas o metodos individuales. De esta forma , uno puede mejora la calidad total de un producto mejorando las CC de las rutinas o metodos.

Procedimiento de calculo de CC para un metodo:

   1. Siempre comenzar con 1: Si fuera llamado, el metodo al menos un camino tiene.
   2. Agregue 1 por cada sentencia condicional o de loop (agregar 1 por un if, while, foreach, operador ternario, etc.)
   3. Agregue 1 por cada AND o OR usado en una condicion.
   4. Agregue 1 por cada bloque case en un select o switch. Si el switch no tiene un case default explicito, agregue 1.
   5. Agregue 1 for cada sentencia catch para una excepcion lanzada.

Despues de este calculo, obtendremos un valor que al menos es 1 (el metodo seria solo una secuencia de sentencias).
Si el resultado está entre 2 y 5 podriamos afirmar que no reviste complejidad de consideración. Entre 6 y 10 tenemos un poco de complejidad para entender que hace internamente. Un valor de CC de mayor de 10 implica que definitivamente el metodo es complejo y deberemos refactorizarlo.

Es valor de CC es una medida del numero de caminos a traves del metodo e indica el minimo numero de tests que necesitamos hacer para poder evaluar y cubrir todos los caminos del metodo. Un metodo de complejidad 10, requiere 10 tests para asegurar que todos los caminos son chequeados. Cuanto mayor cantidad de pruebas de cobertura podamos hacer, mayor sera la calidad del codigo.

Generalizando el calculo…
El numero de cajas de decision es quien define la complejidad del codigo. A mayor cantidad de puntos de decision, mas bugs pueden ser introducidos. El calculo de la CC puede hacerse a partir del flowchart de un metodo o rutina. Contamos el numero de bordes (flechas), numero de nodos (cajas y rombos), restamos este ultimo del primero y agregamos 2 (uno por la flecha para ingresar al flowchart y otro para salir). Nos queda:

CC = E – N + 2.

En el ejemplo, el numero de flechas es 13, el numero de cajas es 11 por lo que la CC es 4. Un punto interesante a notar es que aunque dividamos una caja en dos conectadas por flecha o unamos dos cajas en una, el valor de la CC no cambia. Otra manera de calcular CC es contar la cantidad de rombos y agregar 1.

CC de un Subsistema

Supongamos que uno tiene una rutina (A) que llama a otra rutina (B), cual seria la CC del subistema completo?. La rutina A necesita una flecha extra para ir a B (la llamada) y una rutina extra para volver (el retorno). El calculo seria el siguiente:
SumCC
 = (EA + EB + 2) – (NA + NB) + 2
 = (EA – NA + 2) + (EB – NB + 2)
 = CCA + CCB
Esto es, la CC de un subsistema es la suma de las CC de sus partes.

Mi conclusión respecto a este punto es que ya el developer cuenta con una herramienta para revisar la calidad del código que produce. Casi todos los IDE incluyen directamente o como plugins/add-ons , tools que permiten el calculo automatico de la CC. Una vez que sabemos ésto, no hay excusas para no probarlo y aplicarlo.

Saludos, Gastón

Fuente: http://www.boyet.com/Articles/PCPlusCyclComplex.html

 

Sobre el compromiso profesional y social

11 Oct

Dando vueltas un rato encontré este video, uno de los mas populares dentro de los difundidos por The Story of Stuff (http://storyofstuff.org), en cual se refleja de manera muy didáctica y crítica, una explicación sobre el funcionamiento del sistema de producción y consumo imperante el mundo.

Terminé de verlo y  me quedé pensando en el rol de cada uno de nosotros, no solo como consumidores, sino como profesionales que participamos muchas veces en este proceso, siendo parte de empresas y organizaciones que trabajan de formas perjudiciales o promoviendo practicas indebidas.  ¿Que postura estamos tomando y con cuanto compromiso desarrollamos nuestra labor?.

Para pensar.

Saludos, Gastón