Requerimientos No Funcionales: Porque son importantes

Todos los Servicios de Tecnología de Información (TI) en algún punto de su ciclo de vida, necesitan considerar los requerimientos no funcionales y las pruebas asociadas a los mismos.

Para algunos proyectos, estos requerimientos implican una cantidad considerable de trabajo y esfuerzos, mientras que para otros no.

Con frecuencia, los requerimientos no funcionales son ignorados o subestimados en la fase de análisis de requerimientos. El error, termina identificándose en la fase de implementación cuando remediarlos implica más trabajo y costo, pudiendo ocasionar que no sean adoptados por los usuarios y clientes.

En este artículo se presenta una definición de que son los requerimientos no funcionales de un servicio de tecnología de información o un sistema, se describen las categorías en las que pueden clasificarse, las posibles consecuencias de no definirlos en la fase de Diseño y algunos ejemplos de requerimientos no funcionales.

La gestión de requerimientos de software es fundamental para mantener los proyectos en alcance, tiempo y presupuesto. También para superar las expectativas del cliente. Inscríbete en el Curso Online de Ingeniería de requisitos

¿Cuando aplicar y no aplicar el desarrollo ágil?

Imagen de: Picasa Web Albums

En tiempos recientes, el empleo de fundamentos y marcos de trabajo de desarrollo ágil se ha extendido en la industria de desarrollo de software y en el ámbito interno de las organizaciones en general.

La amplia difusión está ocasionando que parezca que pueden aplicarse a cualquier tipo de proyecto, aunque en muchos casos esté respondiendo realmente a una moda en lugar de a una necesidad concreta.

En este artículo se describen algunos factores a considerar para saber si conviene aplicar un enfoque ágil o no, tales como: Evaluación de la naturaleza del problema, evaluación del conocimiento de la solución técnica al problema que tenga la organización y el equipo de trabajo, así como otros factores de la cultura de la organización.

Presentamos a continuación los factores a considerar para aplicar (o no) los fundamentos del desarrollo ágil:

La nueva guía del PMBOK 5ta Edición

imagen de: amazon.com y amazon.es 

Atención: La nueva guía del PMBOK sexta (6ta) edición ya fue publicada por el PMI.

El 1 de Enero de 2013, el Project Management Institute (PMI) público la nueva "Guía de Fundamentos para la Dirección de Proyectos (Guía del PMBOK)" en su quinta edición. La Guía contiene estándares actualizados para la gestión de proyectos, que son reflejo de la colaboración y conocimiento de un sin número de profesionales que colaboran con el PMI.

En su versión impresa, la guía está disponible solamente en inglés, en librerías como amazon.com. Adicionalmente, la guía está disponible tanto en inglés como en español para los miembros de pmi.org. La versión impresa de la nueva guía del PMBOK en español se espera para 2014.

¿Interesado en comprar el PMBOK 5ta edición en amazon.com?, le recomendamos hacer click en los siguientes enlaces:

>> Latinoamérica (amazon.com)
>> España (amazon.es)

Se presenta a continuación las novedades y cambios de la nueva Guía del PMBOK:

Errores comunes en Bases de Datos: Lógica de negocios en Triggers

Imagen de: Picasa Web Albums

Con este artículo se realiza el lanzamiento de la nueva serie de "Errores comunes en Base de Datos", dedicada a describir los anti patrones de mayor referencia exclusivamente en desarrollo de base de datos y Programación en Structured Query Language (SQL).

En esta primera entrega se presenta el anti patrón de "Lógica de Negocio incluida en Desencadenadores", también conocido como Triggers, el cual se presenta cuando se utilizan los Triggers para la ejecución de cambios en ciertos datos desencadenadas por inserciones o actualizaciones de otros datos.

Al igual que otros anti patrones, no existe una posición unánime en la comunidad y los bandos que están a favor o en contra presentan cada uno las ventajas y desventajas de usarlos.

A continuación se describe el Anti Patrón de Lógica de Negocio en Descencadenadores:

Microsoft Project Professional 2013: Novedades y Características

Imagen de: Microsoft Project

Microsoft Project Professional es uno de los Software de administración de proyectos de mayor uso, su próxima versión, "Microsoft Project Professional 2013" es la sucesora de Microsoft Project 2010. Esta versión fue liberada para fabricación por Microsoft en Octubre 2012, en Noviembre se hicieron disponibles versiones de prueba (Trial de 60 días), y está planeado que esté disponible en tiendas en el primer trimestre de 2013. Microsoft Project Professional forma parte del paquete Microsoft Office 2013.

En este artículo se describen algunas de las novedades y nuevas características de Microsoft Project 2013, tales como: Nueva interfaz gráfica de usuario, nuevas plantillas de proyectos, herramientas para presentación y reportes, integración con Microsoft Office, extensiones disponibles en la tienda office y Project On Demand.

¿Y que opina usted de Microsoft Project?, le invitamos a brindarnos sus opiniones a través del foro de discusión de la web de La Oficina de Proyectos de Informática. ¿Recomendaría Microsoft Project, si conoce algún otro software de administración de proyectos puede también hacer mención en el foro.

Presentamos a continuación las novedades y características del Project Professional 2013.

Refactorización: 6 preguntas y respuestas

Imagen de: Picasa Web Albums

Una de las técnicas más importantes en el desarrollo ágil de software y en particular del Test Driven Development (TDD) es la Refactorización, la cual consiste en hacer modificaciones al código existente para mejorar su diseño de forma tal que no afecte su comportamiento externo.

Está técnica es la que permite implementar en la práctica uno de los valores de la programación extrema (XP) y del desarrollo ágil de software que es la simplicidad.

En este artículo se describe el concepto de refactorización, razones para aplicarlo, tipos de refactorizaciones, beneficios, lo que la práctica permite hacer, entre otros aspectos.

Presentamos a continuación el artículo sobre Refactorización:

Errores comunes en el desarrollo de software: Singletonitis

Imagen de: Wikipedia commons

Se presenta a continuación una nueva entrega de la serie "Errores comunes en el desarrollo de Software". En esta ocasión se describe el anti patron de "Singletonitis", que consiste en el uso abusivo del patrón "Singleton" (Instancia única).

El anti patrón "singletonitis" se manifiesta con el uso excesivo de "singletons" (instancias únicas), en el código, inclusive cuando no se necesitan. Es difícil de detectar hasta que es demasiado tarde para hacer algo para remediarlo.

Entre los problemas que puede ocasionar destacan incremento en el acoplamiento de la aplicación, problemas de sincronización en aplicaciones multi hilo (threads), alto impacto cuando se necesitan modificar, entre otros.

A continuación se describen las características, tipo, problemas ocasionados y la solución del anti patrón de "singletonitis".

Lanzamiento del dominio www.pmoinformatica.com

Tenemos el agrado de anunciar que ahora la Web "La Oficina de Proyectos de Informática" cuenta con su propio nombre de dominio en la Web. Te invitamos a visitarlo en el siguiente enlace:

http://www.pmoinformatica.com/

Asimismo, te invitamos a mantenerte en línea con nuestros artículos, por medio de los distintos medios de suscripción.

• Lista de Correo: Ingresando tu email en "Síguenos por email".
• Síguenos en Twitter por medio de este enlace @PMOinformatica o haz click en el botón "Seguir".
• Síguenos en Facebook en este enlace www.facebook.com/PMOInformatica o haz click en el botón "Me Gusta".
• Suscripción a nuestro Feed RSS por medio de "Suscribirse a" en la barra izquierda.

5 pasos para una delegación efectiva

Imagen de: Picasa Web Albums

Continuando con la serie sobre Gestión de Proyectos en la fase de ejecución, en particular sobre el tema de la delegación efectiva de actividades urgentes e importantes, en este artículo se presentan 5 pasos a seguir para una delegación efectiva basada en el desarrollo profesional de la persona, que son: Evaluar las necesidades de la organización, identificar los colaboradores potenciales, delegar progresivamente, comunicar el porqué y luego evaluar y reconducir en función de los resultados.




Se presenta a continuación los 5 pasos para una delegación efectiva:

TDD: Componentes difíciles de probar

Un factor crítico de éxito del Test Driven Development (TDD) es la automatización de pruebas unitarias, pues son estas las que permiten los ciclos de iteraciones rápidas, necesarios para aplicar de forma éxitosa la práctica TDD.

Sin embargo, se presentar dificultades cuando deben probarse componentes externos al software que se está desarrollando.

En este artículo se describen cuales son las áreas que tienen a presentar problemas, como por ejemplo bases de datos y la interfaz gráfica.

Asimismo, presenta un enfoque para enfrentar este reto, por medio de la abstracción y aislamiento de los segmentos de código difíciles de probar.

Presentamos a continuación las áreas difíciles de probar y el porqué:

Errores comunes en el desarrollo de software: Base de datos como comunicador de procesos

Imagen de: Hargreaves, M, Picasa Web Albums

Se presenta en esta entrega un nuevo artículo de la serie acerca de errores comunes de programación. Otro de los anti patrones de diseño de software que afecta tanto a la aplicación como a las bases de datos es el de “Base de datos como comunicador de procesos”. Este anti patrón consiste en hacer un uso adecuado de la base de datos para “transmitir” información entre procesos. Se observa por ejemplo cuando se utiliza la base de datos para representar los diferentes estados de un flujo de procesos.

Los anti patrones representan herramientas útiles para aplicar las buenas prácticas de programación, pues estos describen "lo que no debe hacerse". En este artículo se describen las características asociadas al anti patrón, tipo de anti patrón, los problemas que este ocasiona y la solución.

Lo urgente y lo importante: Tareas que no deben delegarse

Imagen de: David Kimball (Picasaweb)

Una habilidad primordial de todo Gerente es el saber delegar adecuadamente las tareas, sin embargo, cuando se delega uno de los riesgos es repartir tareas indiscriminadamente. A continuación un nuevo artículo de la serie "Lo urgente y lo importante", en el cual se describirán las tareas y responsabilidades que un líder nunca debe delegar.

El artículo describe las tareas que nunca deben delegarse, tales como las que son responsabilidad directa del líder, coordinador o Gerente, tareas que quien las delega no estaría dispuesto a realizar, por ejemplo por ser poco motivadoras o inclusive que representen un riesgo y tareas que estén fuera del alcance del delegado.


Presentamos a continuación algunas recomendaciones para una mejor delegación de tareas:

Test Driven Development (TDD): Pruebas de desarrollador

.

Continuando con la serie sobre Test Driven Development (TDD), en este artículo se describen lineamientos y conceptos relacionados con las pruebas de desarrollo, práctica que es necesario dominar antes de implementar prácticas ágiles como TDD.

Antiguamente las pruebas de desarrollo se conocían como “pruebas unitarias”, sin embargo el concepto ha sido ampliado, dado que en hoy en día, cada vez más se ejecutan también pruebas integrales en los ambientes de desarrollo.

En el artículo se describen los lineamientos para implementar una práctica de pruebas de desarrollo y las cualidades que deben tener estas pruebas, en cuanto a que sean rápidas de configura y ejecutar, que sean aisladas (no dependan de pruebas previas o que deban ejecutarse en cierto orden), deben ejecutarse lo antes posible, sobre pequeñas unidades de código, entre otros aspectos.

Presentamos a continuación los lineamientos y cualidades que deben tener las pruebas de desarrollo: