Sign In  
Skip Navigation Links
Skip navigation links
Home
Search
Skip Navigation LinksBlogs de TI-M > Rogelio Ramírez
View All Site Content
Categories
Calidad de software
CMMI
Ingeniería de software
Procesos
Usabilidad
Otros Blogs
Calidad TI-M
Ligas
Software Engineering Institute
software.net.mx
Revista Software Gurú
Ayudando a evolucionar la ingeniería del software en México
November 17
Los enemigos del desarrollo de software
by  Rogelio Francisco Ramírez RamírezNo presence information  on 11/17/2010 4:46 PM

Después de algunos años de trabajar en diferentes empresas, algunas relacionadas con la industria del software y otras no, he observado de manera recurrente una serie de problemáticas que generalmente no son atendidas simplemente porque no se consideran problemas. A estos problemas les he denominado “los enemigos del desarrollo de software” y los enlisto a continuación:

 

  • Falta de preparación de los profesionistas de tecnologías de información
    • Ya sea porque las universidades no mantienen actualizados sus programas o porque dichos programas sí están actualizados pero no son bien aprovechados o que las empresas no invierten en la capacitación de su personal, existe un gran número de profesionistas de TI que no cuentan con la preparación adecuada en algunas o todas las especialidades relacionadas con el desarrollo de software.
  • Falta de aplicación de ingeniería
    • En muchas ocasiones se prefiere el uso de prácticas que impliquen el menor esfuerzo posible, la menor capacidad matemática y el menor uso de la estadística posible.
  • Optimismo extremo
    • En ocasiones el optimismo provoca que se hagan estimaciones que no son realistas, que no se identifiquen de manera adecuada algunos riesgos o que no se tomen acciones de prevención que son indispensables para mantener bajo control un proyecto de desarrollo de software.
  • Comunicación deficiente
    • Entre la gente del área comercial y el área técnica
    • Entre los líderes de proyecto y los miembros de su equipo
    • Entre los desarrolladores e ingenieros de pruebas
    • Entre los miembros de un mismo equipo.
    • Etc.
  • Existencia de profesionistas no aptos
    • Existen personas que ingresan a una carrera relacionada con tecnologías de información y deciden continuar en ella aún cuando no comprenden los fundamentos del desarrollo de software tales como la programación orientada a objetos, la lógica matemática, el código binario, la teoría de conjuntos, la estadística y otros rubros. Estas personas egresan de las universidades sin tener la capacidad adecuada para desempeñarse en la industria del software.
  • Incorrecta selección del personal
    • Muchas empresas que ofrecen servicios de desarrollo de software no cuentan con filtros adecuados de selección de personal con base en las competencias y habilidades de cada persona, incluso algunas no cuentan con los filtros adecuados en el ámbito técnico.
  • Asignación arbitraria de personas a cada rol
    • Con el pretexto de la falta de tiempo de algunas personas o la sobrecarga de trabajo, en ocasiones se delegan actividades a personas que no están capacitadas para desempeñarlas.
  • El recorte de esfuerzo, duración o costo derivados de la necesidad de vender
  • La falta de estandarización de medidas en la industria.
    • Para poder establecer mecanismos adecuados de cotización de proyectos de software que permitan comparar a diferentes proveedores con los mismos criterios y así evitar la selección de proveedores que ofrezcan los precios más bajos.
  • El miedo a mostrar que no se tiene conocimiento
    • Lo he visto principalmente en los desarrolladores que no se atreven a decir que no podrán con alguna asignación a pesar de que saben que no tienen el conocimiento técnico necesario para desempeñarla adecuadamente.
  • El “sentido de urgencia” provocado sin fundamentos
    • Particularmente estoy en contra de este “sentido de urgencia” cuando se utiliza para hacer creer que se es buen líder.
  • La ignorancia
    • La falta de conocimiento de metodologías, prácticas, técnicas, modelos y otros instrumentos que permiten agilizar el desarrollo de software.
  • La falta de compromiso
    • Recientemente he entendido que algunas personas simplemente no están interesadas en comprometerse con algo. No pueden comprometerse con una fecha, no pueden comprometerse con un entregable, etc. Y el no poder tener un compromiso de alguien incrementa la incertidumbre que por naturaleza ya existe en los proyectos de desarrollo de software.
  • La malinterpretación de la verdadera labor del líder del proyecto
    • Este es uno de mis enemigos más odiados. Me refiero a las ocasiones en que se asignan  personas que no tienen las habilidades interpersonales para dirigir a otras personas. Esta falta de habilidades combinadas con la falta de conocimiento de los métodos, procedimientos y técnicas de administración de proyectos puede convertirse en un grave problema cuando la persona considera que lo único que debe de hacer es supervisar constantemente a todas las personas por igual porque si no lo hace así, considera que no está realmente trabajando, pero se olvida de emplear todas las herramientas de administración de proyectos para realmente controlar el proyecto.
  • Transmisión informal de prácticas
    • Sucede que aunque existan procesos publicados y conocidos, para muchas personas es mucho más fácil preguntar cómo deben hacer las cosas a otros compañeros de trabajo. Esta forma de trabajar genera un efecto de “teléfono descompuesto” que termina provocando que las prácticas no se ejecuten como deben de ser.
  • La falta de definición de procesos de los clientes
    • Un cliente que no tiene procesos definidos tratará de definirlos, sin hacerlo de manera consciente, mientras se recopilan requerimientos de sus aplicaciones, esto provocará que existan demasiados cambios o inclusive contradicciones entre el personal de la empresa cliente.
  • Exceso de metodologías
    • Hoy en día existen tantas metodologías y modelos de procesos que para una empresa es difícil decidir cuál es el adecuado a sus necesidades.
  • Poco uso de metodologías
    • En la actualidad existen personas que aún no se dan cuenta que requieren implementar y adaptar metodologías existentes. Pero el peor de los casos es el de las empresas que ya implementaron una metodología, la adaptaron a sus necesidades y simplemente no la emplean cuando deben de emplearla y cómo deben de emplearla.
  • La falta de documentación
    • Se sigue dejando el conocimiento en las personas y por lo tanto sigue habiendo dependencia de las personas cuando hay que modificar o actualizar aplicaciones.
  • La documentación por cumplir un requisito
    • Este es uno de los peores, además de que se pierde tiempo tratando de cumplir un requisito, ni si quiera se cuestiona y mucho menos se intenta entender cual es el objetivo de hacer cierta documentación.

 

Considero que en la medida en que una organización dedicada al desarrollo de software logre enfocar sus esfuerzos en resolver muchos de estos problemas tendrá proyectos éxitosos y tendrá clientes y colaboradores muy satisfechos.

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
October 20
SEMAT
by  Rogelio Francisco Ramírez RamírezNo presence information  on 10/20/2010 12:21 PM

La ingeniería de software se está redefiniendo ¿estás listo para lo que viene?
http://www.semat.org

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
September 17
Factores de éxito y fracaso al emplear un modelo de procesos
by  Rogelio Francisco Ramírez RamírezNo presence information  on 9/17/2010 2:08 PM

1. Factores de fracaso al emplear un modelo de procesos

1.1 Acciones y omisiones que llevarán al fracaso

  • No usar un modelo de procesos.
  • No involucrar a quienes emplearán los procesos derivados de las prácticas propuestas en el modelo.
  • No adaptar el modelo a la cultura y necesidades particulares de la organización, área, unidad de negocio o proyecto.
  • Omitir prácticas que son indispensables para la elaboración de un producto o entrega de un servicio. Las prácticas se deben podar, más no mutilar.
  • Emplear las prácticas de una manera incompleta, es decir, sin considerar todos los elementos relacionados con dicha práctica. Esto ocurre comúnmente porque las prácticas se transmiten de persona a persona y no a través de capacitación o de la lectura y comprensión de los modelos.
  • Establecer políticas coercitivas para el cumplimiento de las prácticas.
  • No mejorar los procesos derivados de las prácticas del modelo.

1.2 Errores y creencias que llevarán al fracaso

  • Creer que el modelo debe ejecutarse al pie de la letra.
  • Creer que las prácticas son un proceso que debe ejecutarse de forma secuencial.
  • Definir procesos que sean exactamente iguales a las prácticas del modelo.
  • Creer que las prácticas o procesos derivados de las prácticas implican trabajo adicional al trabajo que ya se realiza actualmente.
  • Creer que el modelo es diferente a otros modelos. Esto ocurre comúnmente por la divulgación de nuevos modelos que están de moda.
  • Creer que el modelo es burocrático.
  • Creer que el modelo no promueve la agilidad en los procesos que derivan de sus prácticas.

2. Factores de éxito al usar el modelo

2.1 Acciones que llevarán al éxito

  • Emplear el modelo para definir y mejorar procesos de trabajo.
  • Involucrar a quienes emplearán los procesos derivados de las prácticas propuestas en el modelo.
  • Adaptar el modelo a la cultura y necesidades particulares de la organización, área, unidad de negocio o proyecto.
  • Incluir todas las prácticas en la definición de procesos que permitan la elaboración de productos o entrega de servicios.
  • Definir, comunicar y ejecutar procesos con base en las prácticas del modelo.
  • Considerar todos los elementos relacionados con cada práctica.
  • Capacitar en el uso de los procesos derivados de las prácticas del modelo.
  • Definir y/o adoptar ciclos de vida que permitan determinar la forma en que se ejecutarán los procesos derivados de las prácticas del modelo.
  • Mejorar los procesos derivados de las prácticas del modelo.

4.2 Aciertos y creencias que llevarán al éxito

  • Creer que, si son bien empleados, los modelos harán el desarrollo de productos, servicios y procesos más ágiles.
  • Creer que, si son bien empleados, los modelos reducirán considerablemente las pérdidas económicas, la insatisfacción de clientes y la insatisfacción de colaboradores que empleen los procesos derivados del mismo.
  • Involucrar a los líderes de opinión de la organización, área, unidad de negocio o proyecto en el empleo de este modelo.
  • Contar con un equipo o comité dedicado a mejorar los procesos derivados de las prácticas del modelo.
  • Leer y comprender todo el modelo.
Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
September 17
La paradoja de los modelos de procesos:
by  Rogelio Francisco Ramírez RamírezNo presence information  on 9/17/2010 9:18 AM

"La gente piensa que sus problemas son causados por emplear modelos de procesos o prácticas que son estándares en la industria, por lo tanto no los usan, pero al no usarlos provocan esos problemas que quieren evitar". Rogelio Ramírez.

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
February 17
Meta-modelo de procesos
by  Rogelio Francisco Ramírez RamírezNo presence information  on 2/17/2010 12:00 PM
Category: Procesos

1. Proceso

Es el conjunto de actividades ejecutadas de manera secuencial o paralela por personas, que asumen un rol y que emplean instrumentos para generar productos.

El proceso existe en la realidad en el momento en que las personas ejecutan actividades.

 

1.1 Modelo de proceso

Es la representación gráfica o escrita de actividades, procesos, instrumentos, productos, roles y las relaciones entre ellos.

 

 

Imagen 1. Meta-modelo de un proceso.

Nota de la imagen: el orden de las actividades y procesos "hijo" se muestra solo como ejemplo.

 

Con el objetivo de poder representar un proceso de forma práctica, simplificada y comprensible, en la empresa, se han dividido los procesos en dos tipos:

  • Proceso dependiente
  • Proceso independiente

 

1.1.1 Proceso dependiente

Es el conjunto de actividades y procesos "hijo" descritos de forma gráfica o escrita para ser ejecutados de manera secuencial o paralela por personas, que asumen un rol y que emplean instrumentos para generar productos.

 

1.1.1.1 Características de un modelo de proceso dependiente

* Si el proceso no tiene actividades, debe tener al menos 2 procesos "hijo" y dichos procesos "hijo" deben contener actividades.

 

1.1.2 Proceso independiente

Es el conjunto de actividades descritas de forma gráfica o escrita para ser ejecutadas de manera secuencial o paralela por personas, que asumen un rol y que emplean instrumentos para generar productos.

 

1.1.2.1 Características de un modelo de proceso independiente

 

1.1.3 Atributos de un proceso

1.1.3.1 Del proceso modelado

  • Nombre

 

1.1.3.2 Del proceso real

  • Duración
  • Costo (de ejecución)

 

1.1.4 Ejemplos de descripciones escritas de un proceso

  • Planear el proyecto.
  • Probar la aplicación.
  • Revisar el documento.

 

2. Producto

Es cualquier cosa producida.

El producto existe en la realidad en el momento en que personas y/o máquinas ejecutan actividades y emplean instrumentos y materiales (por ejemplo: código reutilizable o plantillas de documentos) para producirlo o modificarlo.

 

2.1 Modelo de producto

Es la representación gráfica o escrita del producto o de todos sus componentes y las relaciones entre ellos.

 

 

Imagen 2. Representación gráfica de un producto.

 

Con el objetivo de poder representar un producto de forma práctica, simplificada y comprensible, en la empresa, se han dividido los productos en dos tipos:

  • Producto externo
  • Producto interno

 

2.1.1 Producto externo

Es cualquier elemento generado durante la ejecución de actividades de uno o varios procesos, durante un proyecto o no, y qué es generado y entregado al cliente considerando las necesidades y requerimientos del mismo.

  1. Características de un producto externo

  • Es vendido y/o entregado a uno o varios clientes, externos o internos.
  • El producto completo o sus componentes pueden contener defectos.
  • Puede ser diseñado.
  • Puede ser probado o revisado.
  • Puede ser instalado, entregado, publicado o distribuido.
  • Puede ser almacenado.
  • Es diseñado, construido, probado o instalado conforme a las necesidades y especificaciones de uno o varios clientes.

2.1.2 Producto interno

Es cualquier elemento generado durante la ejecución de actividades de uno o varios procesos, durante un proyecto o no, qué es generado para planear, monitorear y controlar las actividades y recursos de un proyecto y/o diseñar, construir, revisar, probar, instalar o distribuir un producto externo. Un producto interno no es entregado al cliente.

 

2.1.2.1 Características de un producto interno

  • No es entregado al cliente.
  • Es generado para ser empleado posteriormente en otra actividad, del mismo proceso o de otro, generalmente durante el mismo proyecto.
  • Puede ser almacenado en algún repositorio de la empresa.
  • Puede ser revisado o probado.
  • Puede contener defectos.

 

2.1.3 Atributos de un producto

2.1.3.1 Del producto modelado

  • Nombre

 

2.1.3.2 Del producto real

  • Dimensión
  • Costo
  • Precio

 

2.1.4 Ejemplos de descripciones escritas de un producto

  • Sistema de administración de proyectos
  • Sistema de administración de recursos humanos
  • Documento de especificación de requerimientos.
  • Documento de arquitectura.
  • Proceso de recopilación de requerimientos del software.
  • Estudio de mercado.

 

2.1.5 Producto de software

Es el conjunto compuesto de una o varias aplicaciones (software) y su documentación asociada, generados o modificados durante la ejecución de actividades de uno o varios procesos durante un proyecto y que es entregado al cliente. Un producto de software, comúnmente es un producto externo, pero puede también ser generado como un producto interno.

 

2.1.5.1 Documentación asociada

Además de la aplicación o aplicaciones (software), se considera parte del producto la siguiente documentación:

  • Requerimientos
  • Arquitectura
  • Diseño
  • Pruebas
  • Instalación (e integración, si es necesario)
  • Manuales (documentos, gráficas, audio y/o video) de uso o ayuda

 

3. Actividad

Es el conjunto de operaciones o tareas ejecutadas por una persona o entidad.

En la realidad, la actividad existe en el momento en que una persona emplea sus habilidades para ejecutar un conjunto de operaciones.

 

3.1 Modelo de actividad

Es la representación gráfica o escrita de la forma en que una o varias personas, en el desempeño de un rol, deben emplear uno o varios instrumentos para generar o modificar uno o varios productos.

 

 

 

Imagen 3. Meta-modelo de una actividad.

 

3.1.1 Características de una actividad

  • Durante su ejecución pueden emplearse uno o más instrumentos.
  • Durante su ejecución pueden crearse o modificarse uno o más productos.
  • Es ejecutada por al menos una persona en el desempeño de un rol.

 

3.1.1.1 Características de una actividad para ser descrita (representada)

  • Está contenida en un proceso.
  • No tiene procesos "hijo".
  • No tiene actividades "hija".

 

3.1.2 Atributos de una actividad

3.1.2.1 De la actividad modelada

  • Clave (para distinguirla como única dentro del universo de actividades)
  • Descripción

 

3.1.2.2 De la actividad real

  • Duración
  • Costo (de ejecución)

 

3.1.3 Ejemplos de descripciones escritas de una actividad

  • Enviar un correo electrónico al cliente.
  • Revisar que se hayan documentado las interfaces de la aplicación.
  • Aprobar los requerimientos.

 

4. Rol

Cargo o función que alguien cumple en alguna situación o en la vida.

El rol existe en la realidad en el momento en que una persona ejecuta las actividades asociadas con las funciones del rol.

 

4.1 Modelo de rol

Es la representación gráfica o escrita de su (del rol) nombre o función al momento de ejecutar actividades empleando instrumentos y creando o modificando productos.

 

 

Imagen 4. Representación gráfica de un rol.

 

4.1.1 Características de un rol

 

4.1.2 Atributos de un rol

4.1.2.1 Del rol modelado

  • Nombre

 

4.1.3 Ejemplos de descripciones escritas de un rol

  • Analista
  • Líder del proyecto
  • Arquitecto
  • Revisor

 

5. Instrumento

Es el conjunto de diversas piezas combinadas adecuadamente para que sirva con determinado objeto en el ejercicio de un oficio. Aquello de que nos servimos para hacer algo. Aquello que sirve de medio para hacer algo o conseguir un fin.

El instrumento existe en la realidad desde el momento que fue creado, sin embargo, tiene su razón de existir en el momento en que es empleado por una persona o máquina para ejecutar alguna actividad.

 

5.1 Modelo de instrumento

Es la representación gráfica o escrita del instrumento o todos sus componentes en el momento en que es empleado por una persona, en el desempeño de un rol, al ejecutar una o varias actividades.

 

 

Imagen 5. Representación gráfica de un instrumento.

 

5.1.1 Características de un instrumento

  • Es empleado para ejecutar una actividad.
  • Puede ser empleado para crear o modificar un producto.
  • Puede ser convertido en un producto.
  • Puede automatizar la ejecución de una o varias actividades.
  • Puede ser empleado para recolectar información.
  • Puede ser empleado para almacenar información.
  • Puede ser empleado para proporcionar información.

 

5.1.2 Atributos de un instrumento

5.1.2.1 Del instrumento modelado

  • Nombre

 

5.1.2.2 Del instrumento real

Ninguno identificado hasta el momento.

 

5.1.3 Ejemplos de descripciones escritas de un instrumento

  • Plantilla de especificación de requerimientos.
  • Sistema de administración de proyectos.
  • Ambiente de pruebas.

 

6. Proyecto

Es un conjunto de procesos y sus actividades ejecutados de manera secuencial o paralela, que pueden repetirse o no, en un periodo definido, por personas, que asumen un rol y que emplean instrumentos para lograr un fin.

 

El proyecto existe en la realidad en el momento en que las personas ejecutan actividades, en el periodo comprendido entre la fecha de inicio y la fecha de fin del mismo.

 

Es común que el orden y la secuencia de las actividades y procesos de un proyecto estén definidos por un "ciclo de vida".

 

6.1 Modelo de proyecto

Es la representación gráfica o escrita de los procesos y actividades que deben ser ejecutados por personas, que asumen un rol y emplean instrumentos para lograr un fin.

 

Imagen 6. Meta-modelo de un proyecto.

Nota de la imagen: el orden de los procesos se muestra solo como ejemplo.

 

6.1.1. Características de un proyecto

  • Tiene una fecha definida de inicio.
  • Tiene una fecha definida de fin.
  • Es la ejecución real de uno o varios procesos y sus actividades.
  • Existe en el momento en que comienzan a ejecutarse actividades a partir de la fecha definida de inicio.
  • Deja de existir en el momento en que dejan de ejecutarse actividades relacionadas con el fin para el que fue creado.
  • Las personas que participan en él, pueden ejecutar o no, actividades relacionadas con la planificación, monitoreo, control y comunicación del estado actual del cumplimiento del fin para el que fue creado.
  • Cuando el fin para el que es creado un proyecto es un producto, la estimación y planeación de la duración, esfuerzo, costo y recursos del proyecto deberán realizarse en función de la dimensión del producto que se vaya a desarrollar.

 

6.1.2 Atributos de un proyecto

6.1.2.1 Del proyecto modelado

  • Nombre

 

6.1.2.2 Del proyecto real

Un proyecto puede ser intangible, pero es real en el momento en que el conjunto de sus procesos y actividades son ejecutados.

 

  • Duración
  • Esfuerzo
  • Costo
  • Precio

 

6.1.3 Ejemplo de descripción escrita de un proyecto

Descripción

Fecha de inicio planeada

Fecha de fin planeada

Responsable

Software para administración de nómina

01/01/2010

30/10/2010

  

1

Recopilar los requerimientos del producto

01/01/2010

28/02/2010

Analista

2

Diseñar el producto

01/03/2010

31/04/2010

Arquitecto

3

Construir el producto

01/05/2010

30/06/2010

Desarrollador

4

Probar el producto

01/07/2010

31/08/2010

Probador

5

Instalar el producto

01/09/2010

30/10/2010

Instalador

 

7. Glosario

Aplicación - Programa preparado para una utilización específica, como el pago de nóminas, formación de un banco de términos léxicos, etc.

Asiduidad - Frecuencia, puntualidad o aplicación constante a algo.

Cliente - Persona que utiliza con asiduidad los servicios de un profesional o empresa.

Cuerpo - Aquello que tiene extensión limitada, perceptible por los sentidos.

Dimensión - Expresión de una magnitud mediante el producto de potencias de las magnitudes fundamentales. Cada una de las magnitudes de un conjunto que sirven para definir un fenómeno.

Fenómeno - Toda manifestación que se hace presente a la consciencia de un sujeto y aparece como objeto de su percepción.

Magnitud - Propiedad física que puede ser medida; p. ej., la temperatura, el peso, etc. Tamaño de un cuerpo.

Modelo - Arquetipo o punto de referencia para imitarlo o reproducirlo. Esquema teórico de un sistema o de una realidad compleja, que se elabora para facilitar su comprensión y el estudio de su comportamiento.

Sistema - Conjunto de cosas que relacionadas entre sí ordenadamente contribuyen a determinado objeto.

Software - Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.

 

8. Anexos

8.1 Recomendaciones para describir un proceso o una actividad

Si su descripción es escrita:

  • Se recomienda que la descripción comience con un verbo en infinitivo.
    • Ejemplos: Enviar un correo electrónico, elaborar la arquitectura, revisar los requerimientos, etc.
  • Se recomienda no incluir nombres de personas. Se sugiere emplear los nombres de roles.
    • Ejemplo: Presentar el reporte de avance al cliente (en lugar de: "Presentar el reporte de avance a Juan Pérez").
  • Se recomienda no incluir nombres específicos de aplicaciones (software). Se sugiere emplear nombres genéricos para las aplicaciones.
    • Ejemplo: Actualizar el avance del proyecto en el sistema de administración de proyectos (en lugar de: "Actualizar el avance del proyecto en Microsoft Project Server".

Si su descripción es gráfica o escrita:

  • Se recomienda identificar los roles por los que será ejecutada.
  • Se recomienda identificar los instrumentos que se emplearán durante su ejecución.
  • Se recomienda identificar los productos que se generarán durante su ejecución.

 

8.2 Características de un proceso efectivo y eficiente

Para que un proceso sea efectivo debe cumplir con las siguientes características:

  • Debe ser aceptado, empleado y mejorado por las personas que ejecutan sus actividades.
  • Debe ser adaptado a las características particulares de cada situación en la que sus actividades son ejecutadas.
  • Debe ser uniforme, es decir una vez que ha sido adaptado, sus actividades deben ser ejecutadas de igual forma en todas las ocasiones, al menos hasta que el proceso sea mejorado.
  • Debe ser mejorado para hacerlo eficiente.
  • Debe ser estándar, es decir, debe ser entendido y ejecutado de igual forma por diferentes personas.
  • No debe ser interrumpido, es decir, no deben existir periodos de inactividad durante la ejecución de sus actividades.

Para que un proceso sea eficiente debe cumplir con las siguientes características:

  • Debe ser ejecutado con el menor número de actividades posible.
  • Debe ser ejecutado con el menor costo posible.
  • Debe ser ejecutado con el menor esfuerzo posible.
  • Debe ser ejecutado en el menor tiempo posible.

8.2.1 Notas acerca de un proceso

 

8.3 Características de un producto con calidad

Para que un producto pueda tener el mayor grado de calidad posible debe cumplir con las siguientes características:

  • Debe ser construido y entregado con el menor número de defectos posibles.
  • Debe solucionar las necesidades o problemáticas por las que fue concebido, diseñado y construido.
  • Debe ser diseñado y construido considerando todos los requerimientos solicitados.
  • Debe hacer más eficiente el trabajo en el que es empleado.
  • Debe ser empleado y aceptado por sus usuarios.
Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
January 23
Windows Ribbon Development
by  Rogelio Francisco Ramírez RamírezNo presence information  on 1/23/2010 2:11 PM
Category: Usabilidad

Es sorprendente como han cambiado las tecnologías desde que hace años dejé de programar. Pero no solo las tecnologías han cambiado, muchos paradigmas también han quedado atrás mientras que otros aparecen. Con eso de que ahora se hace mucho hincapié en la usabilidad es posible encontrar nuevas formas de hacer las cosas en las aplicaciones.

La primera vez que usé el Ribbon en una aplicación de Office, creo que fue en Word, reaccioné negativamente, habían desaparecido todas las opciones que conocía, ya no podía encontrarlas. Como era de esperarse, después de un tiempo, me acostumbré. Sin embargo, no fue hasta ahora que comencé a programar el Ribbon para nuestro "Administrador de procesos", que me di cuenta de lo práctico que, como usuario, puede llegar a ser.

Para empezar, es importante entender que tomar las decisiones del número de tabs, grupos, botones y su distribución, no es una tarea sencilla, hay que tomarse el tiempo adecuado para entender que será lo más práctico y útil para el usuario. De ahí que Microsoft haya publicado un proceso para el diseño del Ribbon (http://msdn.microsoft.com/en-us/library/cc872781.aspx) y unas guías de usabilidad para el mismo (http://msdn.microsoft.com/en-us/library/cc872782.aspx).

Por otro lado, es importante entender que el Ribbon es un elemento nuevo que solo se emplea en las aplicaciones de Office, aunque Microsoft ya ha comenzado a implementarlo en aplicaciones Web tales como el Project Server 2010. Por lo tanto, mi sugerencia es que al agregar el Ribbon a una aplicación, se deben respetar los tabs comunes establecidos en las aplicaciones de Office, tales como el "home", "Insert", "Layout", "View" y otros.

Si estás dispuesto a entrar en la ola de los que adaptan la tecnología temprano, comienza a leer la documentación que Arik Poznanski ha posteado para quienes estén interesados.

En conclusión, la experiencia de programar el Ribbon hace que uno entienda mejor como funciona, haciendo así que la experiencia de uno mismo, como usuario, sea más enriquecedora en beneficio, no solo de uno, sino de los usuarios de su aplicación.

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
January 23
Patrones de diseño
by  Rogelio Francisco Ramírez RamírezNo presence information  on 1/23/2010 1:19 PM
Ahora que he estado trabajando en nuestra "Plataforma unificada de procesos" entendí la importancia de implementar patrones de diseño en cualquier aplicación. Aunque el proceso de comprensión es tortuoso, vale la pena.
 
Lo que me ocupa en este momento es pensar en cómo se pueden implementar estos patrones a nivel organizacional, sobre todo debido a la resistencia natural al cambio.
 
Tal como me pasó con los procesos, me pregunto ahora cómo fue posible que hubiéramos estado tanto tiempo sin tenerlos (me refiero a los patrones de diseño).
 
Por lo pronto, mi sugerencia cuando se trate de sistemas que se componen de al menos 2 tipos de aplicaciones tales como Web, Windows o móvil se emplee el patrón de MVP (Model View Presenter). Por supuesto que dependerá de la aplicación particular, las circunstancias y decisiones que afecten la arquitectura de la misma.
Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
August 03
Los proyectos de software deberían de ejecutarse como los SCAMPIs
by  Rogelio Francisco Ramírez RamírezNo presence information  on 8/3/2009 10:44 PM
Category: CMMI
El día de hoy recordé, gratamente, el porque me había gustado tanto el SCAMPI que hicimos para nuestra empresa. En resumen, durante un SCAMPI tipo A:
 
  • El líder se hacer responsable de lo que le corresponde y toma el control.
  • Todo se ejecuta prácticamente de la forma en que se planeó.
  • El modelo de evaluación se adapta de acuerdo a la compañía.
  • Se selecciona a las personas indicadas para la evaluación, de acuerdo a su experiencia, formando equipos de alto desempeño.
  • Se involucra de forma adecuada a los participantes.
  • Se capacita a los nuevos integrantes.
  • Se establecen metas y compromisos. Y lo mejor es que: ¡se cumplen!.
  • ¡Se emplean los instrumentos!
  • Se emplean los instrumentos de la manera adecuada.
  • ¡Se sigue el método!
 
¡Hay éxito! y de acuerdo a mis experiencias: ¡sin retrasos! ¡con los miembros del equipo satisfechos! y ¡cumpliendo el presupuesto y alcance!
 
Espero poder capitalizar pronto esta experiencia tan agradable para el beneficio de la empresa.
Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
June 03
Agilidad y burocracia en el desarrollo de software
by  Rogelio Francisco Ramírez RamírezNo presence information  on 6/3/2009 10:26 AM

Quise poner este título que por sí solo genera controversia entre todos los que estamos involucrados de alguna u otra forma con el desarrollo de software, sin embargo, mi intención no es demostrar cuál es la mejor estrategia, filosofía o modelo para desarrollar software, más bien quiero dejar claro por qué creo que estos temas son tan polémicos, con la intención de que el lector pueda vislumbrar el camino que lo lleve a tener una opinión mejor informada, cualquiera que sea su preferencia con respecto a dichas filosofías, modelos o estrategias para desarrollar software.

 

Construir software, como muchas otras actividades de la vida, es una actividad compleja. Fundamento mi argumento en los siguientes enunciados:

 

El software es creado por personas y las personas cometemos errores. Por lo tanto, el software siempre será propenso a contener defectos, derivados de los errores cometidos por las personas que lo diseñaron, construyeron, probaron o implementaron.

Es imposible predecir y controlar todo lo que sucederá en el futuro. Por lo tanto, aun cuando la planeación del proyecto y todas las estimaciones del mismo estén fundamentadas en los conocimientos de personal altamente experimentado o en bases de datos históricas que contengan información detallada de proyectos anteriores, nadie puede saber y nadie puede controlar completamente lo que pasará durante todo el proyecto de desarrollo del software.

Entre mayor sea el número de personas que participan en un proyecto de desarrollo de software mayor es el número de relaciones de comunicación que deben existir. Esta “red” de relaciones que puede llegar a crearse, agrega complejidad, en una magnitud que desconozco, al proyecto y al software mismo.

La tecnología (compiladores, computadoras, frameworks, software, servidores, documentos, diagramas, etc.) usada para diseñar, construir, probar, implementar o contener (ejecutar) el software fue creada por personas y las personas cometemos errores. Nuevamente, no importa en qué proporción, el diseño, construcción, pruebas e implementación del software, dependen de alguna tecnología que, seguramente, tiene defectos puesto que fue creada por personas.

El software es creado por personas y cada persona cuenta con conocimientos y experiencias personales diferentes. Por lo tanto, la forma en que cada persona aplica sus conocimientos y experiencia durante la creación del software es diferente, agregando así otro factor de complejidad en el momento en que cada persona debe asimilar e interpretar los productos del trabajo hecho por los demás, sin importar de qué productos hablemos. Dicha asimilación e interpretación del producto siempre será diferente de la expresión original del producto por parte de quien lo generó, en menor o mayor medida.

 

Si consideramos estos y otros factores presentes en cada proyecto de desarrollo de software podríamos pensar que ningún proyecto de desarrollo de software puede tener éxito (estableciendo como éxito el hecho de que termine en el tiempo, esfuerzo y costo en que fue planeado, además, cumpliendo todos los requerimientos solicitados y dejando satisfechos a quienes pagaron por hacerlo o a quienes lo usan).

Si se plantea de esa forma, quizá el panorama no sea tan alentador, sin embargo, creo que, si crear software teniendo éxito fuera imposible no habría toda una industria creciente en la actualidad. Entonces, ¿por qué menciono todo lo anterior? Bueno, por algo muy sencillo:

 

Considero, con conocimiento de algunos casos, que todos o la mayoría de los modelos, filosofías y metodologías fueron creados para solucionar alguno de estos o todos los problemas mencionados, inclusive otros que no están listados aquí.

 

Partiendo de este punto quiero aportar lo siguiente:

La adopción de un modelo, filosofía o metodología particular no es la solución única a los problemas del desarrollo de software, ni la solución al problema de la “burocracia”, si durante su implementación no se tienen en cuenta los siguientes factores:

·         La experiencia y conocimientos de las personas que implementen y adopten dicha filosofía, metodología o modelo.

·         Las necesidades particulares de quienes adopten dichas filosofías, metodologías o modelos.

·         La definición o indefinición de formas de trabajo estándar de la compañía que desarrolla el software.

·         La filosofía y objetivos de la compañía (las personas que la dirigen o poseen) que construye el software.

·         El conocimiento, la experiencia y la interpretación de técnicas y formas de trabajo de las personas que participan en los proyectos de desarrollo del software.

·         La experiencia de la(s) persona(s) que dirige(n) y controla(n) el proyecto de desarrollo de software.

·         Los intereses, objetivos y visión de quienes pagan por hacer el software o de quienes lo van a usar.

·         El nivel de cohesión del equipo de trabajo del proyecto.

·         La confiabilidad de la información con la que se cuente en el proyecto.

·         La capacidad técnica de las personas que diseñan, construyen, prueban e implementan el software así como la capacidad técnica de quienes lo administran y controlan (si es que esto último sucede durante el proyecto).

·         Los intereses y objetivos de quienes venden el software.

 

En general, lo que trato de decir es que, desde mi punto de vista, no se puede culpar solamente a un modelo, metodología o filosofía del éxito o fracaso de un proyecto de desarrollo de software, ni mucho menos del éxito o fracaso de una compañía que construye software. La mayoría de los modelos y metodologías existentes pretenden resolver los mismos problemas con un conjunto de prácticas, que irónicamente (por las discusiones que se presentan), en la mayoría de los casos son las mismas, es decir, la “forma” cambia, pero el “fondo” es el mismo.

El ejemplo que comúnmente pongo, es el de CMMI (Capability Maturity Model Integration), que para muchas compañías pequeñas, aparentemente es un modelo muy extenso, muchos hasta creen que burocrático, sin embargo, la mayoría de las personas con las que he platicado al respecto, desconocen el hecho de que CMMI sugiere la adaptación de los procesos de una compañía para cada proyecto, dependiendo de las características particulares del proyecto (cliente, recursos, tiempo y presupuesto disponible, etc.), hecho, que desde mi punto de vista, lo hace "altamente flexible", además, solamente establece “que” debe hacerse, pero no establece “como”. Y muchas veces, en esa interpretación del “como” es dónde se implantan procesos burocráticos, que muchas veces tienen más que ver con las políticas, objetivos e intereses de la compañía que implementa el modelo, que con el modelo en sí.

En casos de las metodologías “agiles”, las prácticas propuestas, comúnmente, están más enfocadas al equipo desarrolladores y solamente a la fase de “construcción” del software (No estoy diciendo que siempre, ni que en todos los casos sea así, pero es lo más común) y no contemplan otros factores que también forman parte de las situaciones que comúnmente se presentan cuando se crea software.

 

Finalmente, quiero invitar al lector, a que antes de abogar “ferozmente” por algún modelo, metodología o filosofía para crear software, conozca los objetivos generales y/o particulares que motivaron la creación de dicho modelo, metodología o filosofía, así como las prácticas que puedan tener en común cada uno de ellos, les sorprenderá darse cuenta que tan similares son.

Y bueno, hablando de modelos, metodologías y filosofías, les dejo esta frase para reflexionar:

"Cuando el mapa y el terreno difieren, confía en el terreno"

Dicho sueco.

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
September 01
El valor de las actividades de calidad
by  Rogelio Francisco Ramírez RamírezNo presence information  on 9/1/2007 2:58 PM
En muchas ocasiones es complicado entender e inclusive comunicar el valor que tienen las actividades de calidad en el desarrollo de software. La siguiente tabla pretende, a través de una estrategia de asociación con riesgos, presentar el valor que tienen estas actividades durante el ciclo de vida de desarrollo de un producto de software.
 
Definiciones
Sistema de software
Programa o aplicación de software desarrollada para cumplir las necesidades y requerimientos de un negocio. Se compone de varios productos de software.
Producto de software
Cualquier documento, código fuente, instalador o archivo generado como resultado de ejecutar una actividad de un proyecto de software.

Proyecto de software
Conjunto de actividades planeadas y ejecutadas para crear productos de software que en conjunto formen un sistema de software.

Sistema de configuración
Sistema de software cuyas funciones principales son almacenar y administrar (obtener, proteger, eliminar) los productos de software generados durante un proyecto de software y controlar sus versiones.
 

Grupo de actividades

Actividad

Producto de software generado

Riesgos asociados en caso de no ejecutar la actividad

Comentarios

Revisiones

Revisar los requerimientos

Registro de defectos

- Los defectos insertados en los requerimientos pueden afectar la arquitectura, diseño, código, pruebas y manuales de usuario e implicar que se invierta tiempo y dinero en la corrección (modificación de todos los productos de software asociados) de estos defectos.

- Los requerimientos pueden quedar incompletos lo que provocaría un incremento en los cambios durante la construcción del sistema de software.

- Los requerimientos pueden ser ambiguos lo que provocaría confusiones y desacuerdos entre los involucrados.

- No se podría detectar si los requerimientos son factibles o no (tecnológicamente, económicamente, etc.) y esto provocaría que se intentara construir un sistema de software que no es factible. Si no se revisa puede detectarse muy tarde que había requerimientos no factibles.

Estadísticamente está comprobado que aproximadamente el 60% de los defectos insertados en un sistema de software fueron insertados durante la fase de levantamiento de requerimientos.

Las revisiones a los requerimientos buscan encontrar el mayor número de defectos posibles para que sean corregidos antes de que el sistema de software sea construido.

Los defectos que se buscan en una revisión de requerimientos son defectos que puedan provocar que el sistema de software no cumpla con lo especificado por el cliente o que no cubra las necesidades específicas del cliente o negocio.

Revisar la arquitectura y el diseño

Registro de defectos

- Los defectos insertados en la arquitectura y el diseño pueden afectar el código, pruebas y manuales de usuario e implicar que se invierta tiempo y dinero en la corrección (modificación de todos los productos de software asociados) de estos defectos.

- La arquitectura puede ser inadecuada para los requerimientos de desempeño requeridos por lo tanto podría no alcanzarse el desempeño esperado.

- La arquitectura puede ser inadecuada para los requerimientos de confiabilidad esperados por lo que podría no alcanzarse al confiabilidad esperada por el sistema de software.

- La arquitectura podría no contemplar objetivos que cubran los requerimientos no funcionales especificados por lo que la calidad (desempeño, disponiblidad, usabilidad, etc.) esperada por el cliente podría no alcanzarse.

- Los patrones de arquitectura podrían no ser los adecuados para el sistema de software particular lo que provocaría la construcción de un producto de software deficiente con respecto a lo esperado.

Las revisiones a la arquitectura y diseño de un sistema de software buscan encontrar el mayor número de defectos arquitectónicos (relaciones entre clases, módulos, sistemas, tablas, bases de datos) posibles para que sean corregidos antes de que el sistema de software sea construido.

Revisar el código

Registro de defectos

- Se insertaría una cantidad considerable de defectos en el código que se detectarían hasta que el personal de pruebas los encuentre o inclusive hasta que el cliente los encuentre con el uso lo que provocaría que se construya un producto con un nivel alto de defectos.

- Se generaría código complejo que puede complicar el mantenimiento futuro del sistema de software.

-Se podría generar código que no cumpla con los requerimientos, la arquitectura y el diseño especificados provocando que se genere funcionalidad no esperada ni acordada con el cliente o que se omita funcionalidad especificada y acordada.

- Se desvía la atención respecto a las actividades que tengan los desarrolladores pues deberán corregir los defectos y atender sus labores habituales en el mismo periodo de tiempo situación que impacta otros proyectos de desarrollo en la terminación puntual de los objetivos de dicho proyecto.

Las revisiones de código tienen varios objetivos:

-Encontrar defectos de programación

-Revisar que se cumplan estándares de codificación, arquitectura, diseño y documentación del código.

-Eficientar el código fuente.

Al efectuar una revisión de código se puede reducir en gran medida el costo por retrabajo en fases de liberación, situación que impacta en la apreciación del cliente hacia el producto entregado por los defectos que se puedan presentar.

Auditorías

Planear, ejecutar, dar seguimiento y reportar resultados de auditorías de calidad

Reporte de no conformidades

- Las mejores prácticas definidas para tener éxito en los proyectos de software podrían no ejecutarse provocando situaciones de conflicto o falla en el proyecto.

- Los productos de software esperados podrían no generarse o generarse de manera no adecuada. Lo anterior provocaría incumplimientos con el cliente.

Las auditorías de calidad tienen dos objetivos:

-Verificar que se ejecuten los procesos

-Verificar la generación adecuada y a tiempo de los productos de software.

Planear, ejecutar, dar seguimiento y reportar resultados de auditorías de configuración

Reporte de no conformidades

- En caso de que los productos de software no sean almacenados en un sistema de configuración se corre el riesgo de perder la información del proyecto almacenada en las computadoras de los integrantes del equipo.

- Si cada miembro del equipo maneja diferentes versiones de los productos de software, principalmente del código fuente, es probable que al momento de unificar se reemplacen funcionalidades implementadas por un programador por las funcionalidades de otro programador.

- Si no existe un control adecuado de los cambios a los productos de software se pueden realizar cambios que no necesariamente cubren las necesidades del negocio o que simplemente están incompletos o son inadecuados provocando gastos en tiempo y dinero por retrabajo.

Las auditorías de configuración tienen varios objetivos:

-Verificar que todos los productos de software seleccionados se almacenen en el sistema de configuración (Source Safe, Team System, etc.)

-Verificar que se administren los cambios a los productos de software previamente aprobados.

-Verificar que se cumplan los estándares de nomenclatura de productos de software

Pruebas

Documentar y ejecutar pruebas unitarias

Reporte de pruebas

- Si los programadores no realizan las pruebas básicas (unitarias) al código fuente que generan entonces, en el caso de que exista un grupo de pruebas, se invertirá mucho tiempo para encontrar los defectos introducidos en el código en lugar de verificar que los requerimientos se hayan cumplido, que es la función principal de un grupo de pruebas. En el caso de que no exista un grupo de pruebas entonces los defectos insertados en el código por los programadores pueden ser, y seguramente serán, encontrados por los usuarios finales durante el uso del sistema de software provocando re trabajo y poca confiabilidad en el sistema de software.

- Si no se realizan pruebas unitarias es probable que no se pueda verificar el correcto funcionamiento de los métodos programados lo que puede generar cálculos o valores incorrectos.

Una “unidad” es el elemento más pequeño en un sistema de software que puede ser probado, generalmente son los métodos y las interfaces de una clase, aunque una clase en algunas ocasiones también se considera una “unidad”. Las pruebas unitarias aíslan estos elementos del sistema completo para probar que cumpla las funciones para las que fue creada (la unidad). Las pantallas de un sistema también son consideradas clases.

Planear, documentar, ejecutar y dar seguimiento a pruebas

Reporte de avance de pruebas

- Los requerimientos solicitados por un cliente pueden no cumplirse lo que provocaría que se invierta tiempo y dinero en agregar la funcionalidad no cumplida o no cubierta.

- Durante el desarrollo del sistema de software podría agregarse funcionalidad no solicitada por el cliente lo que provocaría una inversión de tiempo y dinero no necesaria.

- El sistema de software podría no funcionar y detener el “ritmo” del negocio provocando pérdidas económicas importantes.

Ejecutar pruebas de software tiene un objetivo principal:

Verificar que los requerimientos de un sistema de software se cumplan.

Las pruebas pueden ser:

De integración (entre clases, entre subsistemas (módulos), entre varios sistemas de software)

Pruebas de sistema

- Funcionalidad

- Desempeño

- Usabilidad

- Estrés

- Etc.

Pruebas de aceptación de usuario

 
Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
1 - 10Next
Alert Me Alert Me