Prácticas para el desarrollo de software

INTRODUCCIÓN

A continuación, se presenta una recopilación de actividades y buenas prácticas recomendadas por la industria del software y que en su gran mayoría han sido aplicadas en proyectos de desarrollo de software a la medida, realizados en áreas universitarias.

Estas prácticas están dirigidas para la consulta del personal de las entidades académicas y dependencias de la UNAM, que participan en el ciclo de desarrollo de software con la finalidad de guiar acerca de las actividades, definición, desarrollo y seguimiento que permitan asegurar que las soluciones satisfacen las necesidades de negocio y lograr que la implementación sea exitosa, que conduzca a mejores resultados en los sistemas desarrollados dentro de la Universidad.

Se contemplan las áreas principales en el desarrollo de sistemas sin considerar un enfoque o metodología específica de administración de proyectos. Estas actividades del desarrollo de sistemas pueden adaptarse al modelo de gestión seleccionado de acuerdo con las características de los proyectos:

  • I. Requerimientos

    1. Identificación y establecimiento del alcance del software
    2. Recopilación de requerimientos
    3. Análisis de los requerimientos
    4. Especificación de los requerimientos
    5. Validación de los requerimientos
    6. Control de los cambios en los requerimientos
  • II. Diseño del software

    1. Selección del diseño arquitectónico
    2. Diseño detallado
    3. Versionado de la base de datos
    4. Documentación de la arquitectura y diseño del sofware
  • III. Construcción del software

    1. Selección de tecnologías
    2. Control de versiones del código
    3. Calidad del código
    4. Desarrollo de componentes reutilizables
    5. Pruebas unitarias
    6. Pruebas de integración
    7. Prácticas de programación segura
    8. Manejo de errores
    9. Documentación de los componentes
  • V. Liberación del software

    1. Liberaciones de versiones
  • IV. Aseguramiento de la calidad

    1. Planificación de las pruebas
    2. Preparación de las pruebas
    3. Aplicación de las pruebas
    4. Seguimiento a los reportes de incidencias
  • VI. Administración de la configuración

    1. Selección de herramientas para el control de versiones

I. REQUERIMIENTOS

Antes de comenzar con el desarrollo de un sistema a la medida es necesario recopilar y analizar los requerimientos que se obtienen a partir de la comprensión de las necesidades expresadas por los usuarios.

Para definir el término requerimiento, se ofrece la siguiente definición:

“… 2. condición o capacidad que debe cumplir o poseer un sistema, componente del sistema, producto o servicio para satisfacer un acuerdo, estándar, especificación u otros documentos impuestos formalmente [IEEE 730-2014 Estándar IEEE para procesos de garantía de calidad de software, 3.2] … Nota 1 a la entrada: Los requisitos existen en diferentes niveles y expresan la necesidad en forma de alto nivel. Un requisito se indica con la palabra "deberá" y, cuando se utiliza, incluye tanto los requisitos opcionales exclusivos como los aplicables. Los requisitos proporcionan valor cuando se entregan, satisfacen o cumplen. Los requisitos incluyen las necesidades, deseos y expectativas cuantificados y documentados del patrocinador, el cliente y otras partes interesadas.” (Institute of Electrical and Electronics Engineers [ISO/IEC/IEEE 24765], 2017).

A continuación, se presentan seis actividades que nos ayudarán a contar con requerimientos definidos, validados y controlados que serán la base para desarrollar una solución de software:

Requerimientos de software

1. Identificación y establecimiento del alcance del Software

En la etapa de definición del proyecto es importante que se invierta tiempo en identificar y establecer el alcance del software para contar con una visión completa del mismo, además de generar una lista de lo que el sistema podrá hacer, es decir, los requerimientos del sistema.

Los requerimientos describen la visión de los involucrados, así como su comportamiento, interacciones con el usuario y el entorno en el que se utilizará. Se obtienen a través del proceso de elicitación, análisis, especificación y validación de requerimientos del software.

Es importante que al iniciar el desarrollo se cuente con un listado de lo que se espera contenga el software y que se vaya afinando conforme se obtiene mayor información, en caso de que no se realice una especificación más detallada como se indica en el punto 4. Para documentar los requerimientos se puede generar una lista de requerimientos o una lista del producto o Backlog (Anexo 1. Listados de requerimientos). Esta lista de requerimientos bastará para contar con una documentación que permita diseñar, desarrollar y probar el producto.

Si se utiliza una metodología tradicional o de cascada, esta lista de requerimientos sí deberá ser lo más detallada posible, sin embargo, es importante que se considere que, aunque se valide la lista, después los requerimientos podrían cambiar a lo largo del desarrollo. Para ello es recomendable que se cuente con un mecanismo que permita llevar el control de dichos cambios (se profundiza en este tema en el punto 6 de esta sección).

2. Recopilación de requerimientos

Como primer paso se ha de seleccionar al menos una de las múltiples técnicas que nos ayudan a recopilar las necesidades de los usuarios y que facilitan el entendimiento de las mismas. Una de las más ocupadas son las entrevistas a los interesados. Es importante que al menos se elija una técnica, a fin de lograr un producto de software que contenga los requerimientos del usuario.

El estándar A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) versión 3.0 menciona técnicas para recopilar los requerimientos, entre las que se encuentran los cuestionarios, prototipos, grupos de enfoque, entrevistas, entre otros ( Anexo 2. Técnicas para la recopilación de requerimientos ). Al seleccionar las técnicas se debe tomar en cuenta a los usuarios involucrados que participarán en las sesiones para contar con el material de apoyo suficiente para realizar las dinámicas correspondientes y se logre un mejor involucramiento e identificación de los requerimientos. Es importante indicar que independientemente de la técnica elegida debe considerarse lo siguiente:

Recopilar requerimientos

Una vez que se han seleccionado una o más técnicas, se realiza la recopilación de los requerimientos. Es importante que al ocupar una técnica se documenten los resultados obtenidos para comprender, complementar, corregir u obtener nuevos requisitos. En caso de haber seleccionado alguna técnica que involucre sesiones de trabajo se puede documentar por medio de minutas, grabaciones de audio o visuales (previo acuerdo con el usuario) o por medio de pizarrones virtuales, por ejemplo, Jamboard de Google.

Las técnicas mencionadas no son exclusivas para la recopilación de requerimientos, pueden ser utilizadas durante la identificación de las necesidades, el análisis, la especificación y la validación de los requerimientos, para ello debemos considerar cuál de ellas es la idónea en cada etapa.

3. Análisis de los requerimientos

De acuerdo con The Guide to the Software Engineering Body of Knowledge (SWEBOK), este proceso consiste en:

Passos requerimientos

Para realizar este análisis es posible hacerlo a través de diferentes técnicas de análisis, como son:

  1. Descomposición funcional.
  2. Modelado de procesos.
  3. Diagrama de actividades o de casos de uso.

Una vez que se ha analizado, se sugiere que los requerimientos obtenidos sean priorizados de acuerdo con el valor que generan y en su caso sean negociados con los interesados del proyecto, generalmente no todos los requerimientos pueden ser realizados por restricciones de tiempo, costo o capacidad de llevarlos a cabo, por lo que una vez identificados y priorizados es posible que deban ser filtrados y excluir aquellos que al menos en el proyecto actual no serán realizados. En el caso de utilizar métodos ágiles, esta definición y priorización se hace en el registro de tareas (backlog). Otros puntos que se toman en cuenta son aspectos regulatorios, políticas, acuerdos, dificultad de implementación, urgencia, entre otros. Algunas técnicas de priorización son:

  • Técnica de clasificación de lista.
  • MoSCoW.
  • Juicio de expertos.
  • Modelo Kano.
  • Priorización a 3 columnas.

4. Especificación de los requerimientos

El estándar IEEE 830:1998 Práctica recomendada para la especificación de requerimientos señala que las características de una buena especificación de requerimientos es que sean correctos, sin ambigüedades, completos, consistentes, priorizados por importancia y/o estabilidad, verificables, modificables y rastreables.

Para especificar los requerimientos, el nivel de detalle usado en la documentación de la especificación puede variar de un proyecto a otro y de acuerdo con las políticas internas de la dependencia universitaria, así como del nivel de complejidad de los requerimientos, en métodos ágiles se emplean las Historias de usuario (Anexo 4. Historias de usuario ), mientras que en cascada son más usados los Casos de uso (Anexo 5. Casos de uso).

Existen diferentes tipos de requerimientos, principalmente pueden clasificarse de forma general en funcionales y no funcionales, como se muestra en la figura siguiente.

Funcionales
¿Qué va a hacer el software?
Funciones del sistema
Entradas
Salidas
Excepciones
No
funcionales
Interfaces externas: con hardware, software o personas
Desempeño: tiempo de respuesta, disponibilidad, tiempo de recuperación
Atributos como: confiabilidad, seguridad, usabilidad, portabilidad
Restricciones de diseño: estándares requeridos, lenguaje de implementación, políticas para la integridad de la base de datos, ambiente de operación, etc.

Figura 1. Requerimientos funcionales y no funcionales. Elaboración propia basada en el estándar IEEE 830 (IEEE, 1998:3)

Es posible documentar de manera más completa la especificación de requerimientos, el estándar 830:1998 indica que las partes esenciales son: introducción, propósito, alcance, definiciones, siglas y abreviaturas, referencias, resumen, descripción general, perspectiva del producto, funciones del producto, características del usuario, restricciones, supuestos y dependencias, requisitos específicos, apéndices e índice.

5. Validación de los requerimientos

Es importante comunicar y validar con los involucrados, los requerimientos especificados de manera iterativa para garantizar que los hayamos entendido, resolver cualquier duda o conflicto sobre los requerimientos, vigilando que sean comprensibles, coherentes, completos y se encuentren aprobados.

Los involucrados que validan los requerimientos suelen ser el patrocinador, directivos y/o usuarios finales, por ejemplo: profesores, administradores del sistema, alumnos o cualquier representante de los miembros de la comunidad universitaria o externo al que esté dirigido el sistema.

Se sugiere presentar al usuario o cliente uno o varios de los productos elaborados para su revisión y validación, algunos de los productos que suelen mostrarse son:

  • Prototipos.
  • Casos de uso / Historias de usuario.
  • Listado de requerimientos / Backlog.

Los prototipos (Anexo 3. Prototipos), comúnmente son un buen medio para validar, ya que facilita la comunicación gráfica de la interpretación del ingeniero de software acerca de los requerimientos de software. Asimismo, los prototipos son útiles en la obtención de nuevos requerimientos, ayuda a reducir la complejidad, simplifica la comunicación y reduce el nivel de abstracción, por lo que la revisión del comportamiento del sistema a través de una interfaz de usuario puede entenderse mejor que mediante descripciones textuales o diagramas.

El uso de prototipos ayuda a identificar problemas estructurales y de navegación en etapas tempranas, que, de no haber este tipo de productos de trabajo serían perceptibles hasta tenerlos en la interfaz real del sistema, para entonces el impacto en tiempo y costo podrían ser mayores. Los problemas de estructura provenientes de la arquitectura de información se evidencian en el etiquetado, comportamiento e interacción, situaciones que en un diagrama no se pueden ubicar.

6. Control de los cambios en los requerimientos

Como se mencionaba al inicio de esta sección, los requerimientos son dinámicos y usualmente se generan cambios, ya que en etapas iniciales del proyecto es común que el usuario tenga una idea genérica de lo que debe hacer el sistema, pero no del detalle de cada una de las funcionalidades. Esto se va obteniendo conforme se tiene más conocimiento de las necesidades a través del análisis y mediante las entregas frecuentes de funcionalidad.

Cuando se identifiquen cambios en cualquier momento del desarrollo de software, como por ejemplo, una vez que ya existen funcionalidades desarrolladas y que posiblemente el cliente las haya validado, se recomienda que los cambios en los requerimientos sean controlados a través de un proceso que consiste en:

Una alternativa sugerida para llevar el registro, es en una relación en un documento de texto u hoja de cálculo. Este registro puede contener los datos: ID, descripción del cambio, módulos afectados, fecha de solicitud, prioridad y estatus. Esta manera suele ser efectiva cuando los cambios deben aplicarse de manera rápida durante la codificación.

II. Diseño del software

Toda actividad en donde planteamos cómo resolver un problema a través de software, forma parte del diseño. Durante la etapa de diseño se toman decisiones respecto a:

  • cómo se almacenan los datos,
  • cómo se verán y usarán las interfaces de usuario,
  • cómo se comunicará el sistema con otros servicios y
  • cómo se delimitan las responsabilidades entre componentes.

A continuación, se describen cinco prácticas importantes para determinar la base sobre la que se construirá el software:

Cinco pasos para el desarrollo de software

1. Selección del diseño arquitectónico

Es recomendable aplicar aquellos estilos y patrones que sean los más apropiados para el sistema que se va a construir. La selección de estos dependerá del tipo y tamaño del sistema en cuestión. Para sistemas transaccionales que involucren muchas reglas de negocio complejas, es recomendable optar por una arquitectura centrada en el dominio (domain-centric architecture).

2. Diseño detallado

Al realizar el diseño de componentes de software, es recomendable conocer algunas buenas prácticas, tales como los principios de diseño SOLID y los principios de asignación de responsabilidades GRASP. También existen patrones de diseño para sistemas orientados a objetos, los cuales documentan soluciones genéricas para problemas recurrentes de diseño.

Se recomienda conocer y aplicar este tipo de soluciones que han sido probadas porque ayudan a que el software se construya fácilmente y sea fácil de comprender y mantener. Algunos libros que hablan al respecto son “Design Patterns. Elements of Reusable Object-Oriented Software” de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides y “Head First Design Patterns. A brain-friendly Guide” de Eric Freeman y Elisabeth Robson.

También es útil conocer los llamados anti-patrones de diseño de software, los cuales son malas prácticas o soluciones que pueden traer problemas a futuro en lo que respecta a la modificación y mantenimiento del software. Algunos de ellos incluyen la creación de clases con muchas líneas de código, las cuales representan una mala división de responsabilidades, así como el lado opuesto, demasiadas clases con pocas responsabilidades. Conocer cuáles son estos anti-patrones ayuda a no caer en ellos cuando se realiza el diseño del software. Existen muchos sitios en Internet que hablan sobre dichos anti-patrones, incluso bibliografía. La más conocida es "Antipatterns: Refactoring Software, Architectures, and Projects in Crisis" de los autores Raphael C. Malveau y William J Brown. Un sitio web muy recomendable sobre anti-patrones de diseño es “Antipatterns” https://sourcemaking.com/antipatterns el cual abarca dicho tópico aplicado al diseño, desarrollo y gestión de proyectos tecnológicos.

Cabe señalar que el concepto de anti-patrones, también existe en otros ámbitos de la Ingeniería del software tales como la Construcción de Software e incluso en la Administración de Proyectos.

3. Diseño de la base de datos

Para el diseño de la base de datos es recomendable:

Diseño de bases de datos

4. Versionado de la base de datos

Una vez iniciada la construcción del modelo, para bases de datos relacionales, es buena práctica controlar las versiones de la base de datos a través de herramientas como Flyway DB o Liquibase. Estas herramientas ayudan a aplicar scripts SQL de manera incremental sobre una base de datos. También permiten borrar fácilmente todas las tablas de una base sin eliminarla.

Algunos marcos de desarrollo incluyen sus propios mecanismos para versionar la estructura de la base de datos y es recomendable conocerlas también para elegir la que mejor se adapte a la realidad de cada proyecto.

5. Documentación de la arquitectura y diseño del software

Es importante que se documente la estructura del software, para tenerlo como referencia para futuras actualizaciones o darle mantenimiento, o en caso de que llegaran a involucrarse nuevos desarrolladores se tenga la base documental. Para ello se sugiere documentar:

Documentación de la arquitectura

III. Construcción del software

De acuerdo con la guía SWEBOK, el cuerpo de conocimientos oficial de la ingeniería del software, la construcción "Consiste en crear software mediante una combinación de codificación, verificación, pruebas unitarias y depuración”. El objetivo principal de la construcción es convertir un conjunto de especificaciones de diseño, en un software que puede ser ejecutado y que funcione conforme a dichas especificaciones.

A continuación, se enlistan las recomendaciones generales a seguir durante la construcción del software:

  1. Selección de tecnologías
  2. Control de versiones de código
  3. Calidad del código
  4. Desarrollo de componentes reutilizables
  5. Pruebas unitarias
  6. Pruebas de integración
  7. Prácticas de programación segura
  8. Manejo de errores
  9. Documentación de los componentes desarrollados

1. Selección de tecnologías

Como primer paso, es relevante conocer si hay estándares que la institución o área universitaria proponga como referencia a emplear, o recomendaciones generales aplicables como podría ser preferir el uso de licencias de software libre. También es conveniente analizar tendencias, así como las plataformas tecnológicas ya usadas en el área en otros proyectos.

Para facilitar y agilizar la construcción, se recomienda también seleccionar el lenguaje de programación más apropiado para el sistema que se desea construir, así como respetar los estándares. Por ejemplo, para un sistema que implique el procesamiento de mucho texto plano podría ser más adecuado el uso de un lenguaje como PERL, el cual ofrece múltiples funcionalidades que facilitan el manejo de texto por encima de lenguajes de propósito general como C.

También es importante contemplar si habrá comunicación con otros sistemas al elegir el lenguaje de programación a utilizar, comparar entre los distintos manejadores de bases de datos para elegir el adecuado e identificar otras herramientas por ejemplo si algún framework puede agilizar la creación del aplicativo o alguna de apoyo para adaptar los sitios de manera responsiva como es Bootstrap.

Existen editores de código fuente que cuentan con extensiones para facilitar las tareas de codificación y depuración, muchos de ellos gratuitos tales como Atom, Visual Studio Code, Netbeans, Eclipse y otros.

En caso de que sean herramientas que no se han utilizado, es importante tomar en cuenta el tiempo que toma aprender dichas herramientas y en su caso solicitar apoyo a las personas que han tenido experiencia previa para tratar de disminuir la curva de aprendizaje. El principio o ley de Pareto también es aplicable a este contexto: basta con aprender un 20% de las características de un lenguaje, marco de trabajo o tecnología, para construir el 80% de funcionalidades en un proyecto, lo importante es saber seleccionar ese 20%.

2. Control de versiones del código

Una de las prácticas esenciales durante la construcción de software es contar con un mecanismo para el control de versiones del código, tales como Subversion, Git u otros similares, que son útiles para controlar y almacenar los cambios y correcciones que ocurren en el código fuente a lo largo de su ciclo de vida. Existen servicios en Internet tales como Github y Gitlab que pueden utilizarse para mantener un respaldo del código del sistema ante cualquier pérdida de datos por fallas en nuestros servidores.

3. Calidad del código

Es recomendable seguir buenas prácticas de programación para contar con un código fuente legible y comprensible que facilite las modificaciones del mismo. Cuando se trabaja en equipo, también es importante establecer estándares de codificación y que todo el equipo esté dispuesto a cumplirlos para mejorar la mantenibilidad del código del sistema, el cual es un factor decisivo en el tiempo de vida de un componente de software. Considera también que es más fácil detectar errores de lógica, seguridad y optimización en un código legible y limpio.

Cada lenguaje de programación y marco de desarrollo plantea sus propias convenciones y estándares de codificación recomendados, es importante conocerlos y seguirlos. También existen herramientas tales como SonarQube que permiten evaluar la calidad del código fuente. Dichas herramientas revisan el cumplimiento de buenas prácticas de codificación que han sido generalmente aceptadas por comunidades de desarrollo de diversos lenguajes de programación. Se recomienda establecer, al interior del equipo de desarrollo, lineamientos que apoyen al equipo actual y a futuras incorporaciones, algunos puntos a considerar son:

Elementos de calidad del software

4. Desarrollo de componentes reutilizables

Para facilitar el desarrollo y mantenimiento del software se recomienda la reutilización, para ello se debe:

Reutilización de componentes

  • Modularidad: Separar la funcionalidad del sistema en partes de la tal manera que se pueda probar y modificar fácilmente.
  • Bajo acoplamiento: En la medida de lo posible cada módulo debe relacionarse poco con otros módulos.
  • Alta cohesión: Cada parte de un módulo debe realizar una única tarea.

Los datos de prueba pueden ser utilizados tanto por el desarrollador como el probador para reproducir los hallazgos identificados.

5. Pruebas unitarias

Las pruebas unitarias o pruebas de unidad, son un mecanismo muy efectivo para comprobar que un componente de software, por ejemplo, una función o el método de una clase se comporta de manera predecible frente a ciertos escenarios. La mayoría de los lenguajes de programación actuales cuenta con un marco de trabajo o librería para la creación de este tipo de pruebas. Una gran ventaja de este tipo de pruebas es su automatización, lo cual facilita las pruebas de regresión cuando ocurre un cambio o corrección en el código fuente.

6. Pruebas de integración

Además de las pruebas de unidad, también se recomienda diseñar y aplicar pruebas a los componentes del software en su conjunto, así como su interacción con el entorno en el cual se ejecuta el sistema. Por ejemplo, si el sistema se conecta a un servidor de bases de datos o a un servicio Web o envía mensajes de correo electrónico, es recomendable tener casos de prueba para comprobar que esas interacciones ocurren sin problemas.

7. Prácticas de programación segura

Se sugiere que los programadores se familiaricen con las vulnerabilidades que son comúnmente explotadas por los hackers maliciosos. Las buenas prácticas de SANS Institute ofrecen una larga lista de verificación de seguridad para el diseño de aplicaciones web. Considerando aspectos como (Bayse, 2004):

  • Evaluación de riesgos.
  • Autenticación.
  • Autorización y control de acceso.
  • Administración de sesiones.
  • Validación de datos y entradas.
  • Cross site scripting (XSS).
  • Inyección de SQL.
  • Buffer overflows.
  • Manejo de errores.
  • Logging.
  • Administración remota.
  • Configuración de la aplicación web y del servidor, de acuerdo con las recomendaciones específicas para el lenguaje de programación utilizado.

Una referencia a tomar en cuenta para la seguridad de software de código abierto es OWASP, https://owasp.org (opens new window)que es una fundación cuya labor es mejorar la seguridad del software.

8. Manejo de errores

Es recomendable que el comportamiento del sistema ante la presencia de un error sea predecible, tanto para mejorar la experiencia de uso de un sistema como para ayudar a la depuración de errores. Se recomienda:

Utilizar archivos de bitácora para guardar aquella información que permita rastrear la causa u origen de un error.

El sistema sea capaz de recuperarse automáticamente ante problemas tales como la desconexión de una base de datos, de un servicio Web o ante entradas de datos incorrectas por parte del usuario.

9. Documentación de los componentes desarrollados

Es recomendable documentar detalles relevantes del proceso de construcción para contribuir al mantenimiento y actualización del sistema. La estructura del sistema se puede documentar a través de:

  • Diagramas de clases.
  • Diagramas de actividades. Mostrar las interacciones entre el usuario y el sistema.
  • Diagramas de secuencias. Mostrar las interacciones entre componentes del sistema.
  • Diagramas de despliegue. Mostrar la relación entre el sistema y otros servicios tales como bases de datos y servidores de correo electrónico.

Se sugiere que la documentación sea significativa, más no exhaustiva

IV. Aseguramiento de la calidad

El aseguramiento de la calidad se lleva a cabo para verificar que se satisfagan las necesidades de los usuarios al revisar que se cumplan los requisitos de software obtenidos, así como aquellos contractuales o legales.

Independientemente del modelo de desarrollo que se elija deben realizarse pruebas para verificar los requisitos del sistema. “Las pruebas de software se definen como el proceso que ayuda a identificar la corrección, completitud, seguridad y calidad del software desarrollado” (Bolaños, 2007), con la finalidad de descubrir defectos y proponer mejoras.

Enseguida se presentan cuatro recomendaciones generales para llevar a cabo pruebas al software desarrollado y que se basan en gran medida en las prácticas promovidas por el International Software Testing Qualifications Board (ISTQB).

Practicas ISTQB

1. Planificación de las pruebas

Las pruebas o testing de software, contemplan una gran variedad de opciones, como pueden ser funcionales o de desempeño, que nos proporcionan visibilidad de que el software funcione o no. El error más común al realizar las pruebas, es encontrar uno o muchos problemas o hallazgos y no haber definido previamente tiempo para regresar al desarrollo y realizar las correcciones. Por lo que es importante considerar en la planificación del proyecto, el tiempo para corregir en código los problemas identificados en las pruebas.

Además de planificar el proyecto se recomienda establecer las actividades necesarias para llevar a cabo las pruebas. Entre los puntos a considerar se encuentran:

01
Establecer el alcance de las pruebas, es decir, lo que se incluye y lo que está fuera "Qué" y el tiempo necesario.
02
Indicar el tipo de pruebas a realizar. En este caso es necesario priorizar los tipos de pruebas a aplicar dependiendo del contexto, sobre todo si se elige una combinación, en algunos casos prevalecerán las pruebas funcionales mientras que en otros serán las pruebas no funcionales como pueden ser de carga (Anexo 8. Tipos de pruebas).
03
Determinar un calendario para aplicar las pruebas. En el calendario se ha de tomar en cuenta el tiempo necesario para aplicar las pruebas, para que el equipo de desarrollo realice las correcciones y para que el equipo de pruebas verifique dichas correciones.
04
Determinar los recursos humanos y materiales que son necesarios. Se sugiere que el equipo que haga las pruebas sea diferente a quien lo desarrolló, además se debe definir si se usará alguna herramienta como pueden ser de gestión, automatización, performance, entre otros de acuerdo con el tipo de pruebas a realizar.
05
Selección de herramientas para reportar incidencias. Los reportes de incidencias o problemas detectados durante las pruebas pueden documentarse de manera muy básica a través de formatos de Excel o Word o bien pueden utilizarse soluciones de herramientas de software libre como: Mantis, Bugzilla o el espacio disponible para registrar incidencias en Git, por mencionar algunas.

Si los probadores cuentan con experiencia en la aplicación de pruebas se sugiere incorporar herramientas para automatizarlas. Por ejemplo WebLoad es una herramienta web que brinda informes acerca problemas de rendimiento de un sitio, de software libre se encuentra Selenium para pruebas de rendimiento, de regresión o funcionales, así como Jmeter para realizar cargas y medir el rendimiento.

2. Preparación de las pruebas

Un paso importante es planear los métodos de revisión y pruebas a aplicar en los componentes de software generados, basados en el diseño creado con este fin, así como en los criterios de aceptación definidos o bien en los requerimientos especificados.

Se recomiendan los siguientes puntos para preparar las pruebas:

  1. Realizar pruebas estáticas mediante la revisión de:
    •  La documentación como pueden ser las especificaciones de requerimientos para detectar ambigüedades o requisitos incompletos.
    • Código para detectar código duplicado o que ya no se ocupa, variables no declaradas, métodos sin usar, entre otros. Como se mencionó anteriormente también se puede aplicar pruebas unitarias y de integración al código, esto es que las pruebas pueden llevarse de manera paralela a cada fase del desarrollo del sistema. Entre más temprana sea la detección de defectos en el código, su corrección suele ser más sencilla y menos costosa.
  2. Elaborar los Casos de prueba a partir de la revisión documental. Los casos de prueba son el “Conjunto de condiciones previas, entradas (incluidas acciones, cuando corresponda) y resultados esperados, desarrollados para impulsar la ejecución de un elemento de prueba para cumplir con los objetivos de la prueba, incluida la implementación correcta, la identificación de errores, comprobación de la calidad y otra información valiosa” (Institute of Electrical and Electronics Engineers [ISO/IEC/IEEE 29119-1], 2013). Estos casos de prueba son el “Cómo”. Las historias de usuario, casos de uso o especificación de requerimientos suelen ser la base para la creación de casos de prueba.
  3. Contemplar una variedad de datos de prueba que cubran las características o condiciones del sistema.
  4. Priorizar los casos de prueba considerando los módulos más críticos.

3. Aplicación de las pruebas

Debido a que en muchos casos es imposible realizar pruebas exhaustivas se recomienda:

  1. Verificar el ambiente en el que se aplicarán las pruebas. Preferentemente las pruebas deben realizarse en un ambiente adicional al usado para el desarrollo del software que contenga una versión estable del sistema y de esta manera evitar conflictos con las entradas y salidas planeadas por los probadores.
  2. Utilizar diferentes datos de prueba usando distintos perfiles y en diferentes ambientes. Para realizar esta actividad se pueden elaborar los casos de prueba.
  3. Aplicar las pruebas siguiendo el orden de priorización de los casos de prueba. En caso de que no se tengan los casos de prueba es posible aplicar pruebas exploratorias para realizar las pruebas mientras se descubre y aprende sobre la aplicación para diseñar nuevas pruebas.
  4. Evitar probar siempre los mismos módulos, para ello se sugiere intercambiar módulos con otros perfiles que realicen pruebas.
  5. Poner mayor atención en aquellos módulos que contienen la funcionalidad más importante, que pueden presentar mayores riesgos o puedan ser más problemáticos, en este caso se habla de una técnica basada en la experiencia.
  6. Reportar los hallazgos identificados durante la aplicación de las pruebas mediante la herramienta seleccionada, adjuntando evidencias como pueden ser videos, imágenes o archivos de salida del sistema.

Sin importar el formato usado, es recomendable que se retroalimente la incidencia reportada lo antes posible. El reporte debe contener elementos como: dato solicitado por el sistema, descripción de la incidencia y el ejemplo o la serie de pasos para lograr replicarlo (Anexo 9. Reporte de incidencia). También se puede considerar incluir el nivel de criticidad de la incidencia, su prioridad de atención, el responsable de atenderla, entre otros.

Para confirmar que se hayan realizado las acciones correctivas y que el software funciona correctamente será necesario realizar pruebas de confirmación para poner énfasis en aquellas pruebas que hubieran fallado en algún ciclo y realizar pruebas de regresión cuando se haya incorporado nueva funcionalidad.

4. Seguimiento a los reportes de incidencias

Además de documentar los hallazgos identificados, es importante dar seguimiento para verificar que se hayan corregido correctamente, ya sea que se haya decidido reportar en un documento de texto o en alguna herramienta de seguimiento de defectos como Mantis. En estos se ha de indicar si el hallazgo persiste (para su atención) o si fue solucionado.

Se recomienda informar los resultados tomando en consideración:

  • Comunicar el progreso de las pruebas y los resultados, por ejemplo, la cobertura de las pruebas al indicar aquello que no ha sido probado, la cantidad de defectos sin corregir de acuerdo con la criticidad, si el sistema se encuentra estable, entre otros.
  • Evaluar si deben realizarse más pruebas, esto mediante la verificación del cumplimiento de los criterios de aceptación. En caso de detener las pruebas y su correspondiente atención, se deben entender y aceptar las consecuencias de no haberse corregido las incidencias pendientes.
  • Actualizar los documentos de trabajo como son casos de prueba o reportes de incidencias.

De igual forma, han de considerarse las pruebas de mantenimiento que son aquellas que se realizan después de que el equipo de desarrollo corrige una anomalía reportada por el usuario o cliente, debido alguna modificación en el ambiente o en los componentes o por alguna migración realizada, entre otros.

V. Liberación del software

Una liberación es una versión de software que se hace disponible formalmente. Esto incluye tanto las versiones externas a los clientes como las versiones internas, por ejemplo, a otro grupo de desarrollo interno o a un grupo de pruebas.

1. Liberación de las versiones

Al terminar el desarrollo de un producto, se realiza la liberación del producto. En un enfoque ágil se tiene preferencia por realizar varias liberaciones pequeñas, considerando que desde el principio se desarrolla el conjunto mínimo de funcionalidad útil, que ofrece valor para el negocio. “... Las liberaciones del sistema son frecuentes y agregan incrementalmente funcionalidad a la primera liberación” (Sommerville, 2011, p. 66).

En esta fase se sugiere que las liberaciones se administren, con el propósito de asegurar que el conjunto adecuado de entregables (incluyendo documentación y materiales auxiliares) se entregue a la parte receptora en la forma, medio y lugar convenidos. Se recomienda que la documentación y los materiales auxiliares se actualicen durante todo el ciclo del desarrollo del software para contar con información vigente que sirva de referencia en cualquier momento.

Se sugiere proveer al usuario o cliente de materiales de ayuda como pueden ser desde tutoriales, manuales de usuario, guías de instalación hasta capacitaciones para contextualizarlos en el uso de los sistemas, el estándar ISO/IEC/IEEE 26512-2007 señala que “... debe proporcionar a los usuarios la información suficiente para ayudarlos a realizar sus tareas durante el uso del sistema. En el propósito de la información proporcionada debe especificarse si se trata de un instructivo, material de referencia, o ambos.”.

VI. Administración de la configuración

A lo largo de las recomendaciones en las fases del desarrollo de software se ha mencionado el control de versiones de los elementos. Los elementos de configuración son aquellos como documentos de especificación de requerimientos, modelado de datos, código fuente, manuales, por mencionar algunos. El alcance de la disciplina de administración de la configuración es importante debido principalmente a que:

Un producto se trabaja por varias personas

Hay diferentes versiones del código de acuerdo con el propósito de los ambientes de trabajo: desarrollo, pruebas o producción.

Existen cambios en los requerimientos de integración de nuevos requerimientos que afectan a varios elementos mencionados, entre otros.

Cualquier cambio en los elementos de configuración del software afectará al producto final. Por lo tanto, toda modificación en los elementos de configuración debe controlarse y administrarse, así como tener la posibilidad de recuperar versiones previas.

1. Selección de herramienta para el control de versiones

El versionado de los elementos de configuración del sistema puede llevarse a cabo de forma manual o mediante el uso de herramientas de software libre, como git y subversion, o bien soluciones comerciales de acuerdo con las necesidades y presupuesto disponible.

En un árbol del control de versiones se muestran algunos elementos generados en los proyectos, que pueden ser documentos y elaborados en un proceso, como son el plan de proyecto, los casos de uso, entre otros. También se puede llevar un control de los archivos con el código fuente generado en desarrollo, por ejemplo, las vistas, controladores y modelos generados en un proyecto de PHP usando un modelo vista controlador; el código de las clases de java; archivos con código de Python u otro lenguaje de programación usado en el proyecto. La siguiente imagen muestra un ejemplo de árbol del control de versiones.

Arbol de control de versiones

Figura 2. Ejemplo de las ramas de control de versiones de los componentes generados en un sistema

 

Anexos

Identificación y establecimiento del alcance del Software

Anexo 1. Listados de requerimientos

Plantilla de Listado de requerimientos

Instructivo de llenado:

  • ID. Número único consecutivo que se utiliza para identificar un requerimiento.
  • Requerimiento. Breve especificación del requerimiento funcional o no funcional que se quiere en el software.
  • Descripción. Información clara y detallada sobre la funcionalidad esperada del requerimiento, incluyendo los criterios de calidad esperados.
  • Prioridad. Se indica si es un requisito obligatorio (debe existir), recomendable (es conveniente pero no forzoso) o deseable (es opcional).

Ejemplo:

Plantilla de lista del producto o Backlog

Instructivo de llenado:

  • ID. Número único consecutivo que se utiliza para identificar la historia de usuario.
  • Historia de usuario. Especificación de la historia de usuario: Como un [Rol], necesito [descripción de la funcionalidad], con la finalidad de [Razón o Resultado].
  • Criterios de aceptación. Se establecen las características y pruebas que debe cumplir el producto para considerar finalizada su implementación y para que sea aceptado. Los criterios de aceptación deben ser consensuados con el cliente.
  • Prioridad. Se indica con un número consecutivo el orden en que debe atenderse, por lo que al inicio del listado se encontrarán los elementos más importantes. El usuario o cliente es quien define la prioridad.
  • Estado. Indica un posible estado: Vacío (La historia se encuentra en proceso de ser detallada), En Proceso (La historia se encuentra en desarrollo), Hecho (La historia fue desarrollada, probada y mostrada al usuario) o Descartada (La historia fue cancelada).

Ejemplo:

Selección de técnicas para la recopilación de requerimientos

Anexo 2. Técnicas para la recopilación de requerimientos

A continuación, se presentan algunas técnicas estratégicas para recopilar los requerimientos.

Entrevista Hacer preguntas relevantes a una persona o grupo de personas de manera formal o informal y documentar las respuestas.
Encuestas y Cuestionarios Distribuir la encuesta o el cuestionario que contenga preguntas relevantes, el cual puede ser abierta o cerrada para analizar los resultados.
Prototipos Detallar los requerimientos de la interfaz del usuario integrando los requerimientos descritos en casos de usos como son datos y reglas de negocio (Anexo 3. Prototipos). Existen diversas herramientas en línea para la elaboración de prototipos, por ejemplo Draw.io, Justinmind, Marvel, entre otros.
Descomposición funcional Representar la estructura jerárquica de un dominio concreto por niveles en el que se lea de arriba hacia abajo y de izquierda a derecha. Para describir el contenido de cada nivel se puede descomponer en otros niveles.
Modelado de procesos Representar visualmente el flujo de las actividades relacionadas con el trabajo que se realiza y entender las áreas o roles involucrados. Las notaciones más conocidas son:
  •  UML (Unified Modeling Language). Se puede ocupar herramientas de uso libre como StarUML o Draw.io.
  •  BPMN (Business Process Modeling Notation). Se puede ocupar herramientas de uso libre como Lucidchart, Bizagi o BonitaSoft.
Revisión de sistemas legados Estudiar el/los sistemas relacionados para identificar:
  • La información relevante.
  • Reglas de negocio que no se encuentren en la documentación.
  • Funcionalidades que no se encuentren descritas.
Análisis de documentos Estudiar la documentación existente de la solución para identificar:
  • La información relevante.
  • Reglas de negocio.
  • Entidades o atributos que tienen que ser incluidos en la nueva solución.
Lecciones aprendidas Compartir los éxitos, fracasos y recomendaciones.
Grupos de enfoque Compartir las impresiones, preferencias y necesidades, el grupo es dirigido por un moderador.
Observación Vigilar al usuario que realiza su trabajo para la comprensión del proceso, en este caso el observador puede permanecer callado o en su caso dialogar con el usuario. Se toman notas.
Análisis causa raíz Identificar los problemas y sus causas clasificándolos, se puede usar los métodos:
  • Diagrama de Ishikawa.
  • Técnica de los 5 ¿Por qué?
Benchmarking Realizar una comparación para evaluar las fortalezas y debilidades de una organización contra sus competidores.

Anexo 3. Prototipos

Al hablar de prototipos nos referimos a crear algo para probar, explorar, o comunicar ideas acerca de las cosas que han de crearse.

Ciclo del prototipado

Figura 4. Elaboración propia basada en el estándar IEEE 830 (IEEE, 1998:3) Ciclo de vida del prototipado.

Existen varios modelos de prototipos que pueden elaborarse, se consideran dos tipos:

  1. El Prototipo Desechable es un esquema realizado en poco tiempo que muestra la idea y sirve para eliminar dudas sobre lo que el cliente quiere y necesita. Iniciamos con una representación de baja fidelidad de la idea, para hacerla crecer en alta fidelidad:
  • Un simple dibujo o bosquejo a lápiz.
  • Uno o varios wireframes.
  • Un conjunto de dibujos y wireframes con interactividad, que permita probar la navegación entre distintas vistas y presentaciones de nuestro proyecto.
  1. El Prototipo Evolucionario es un modelo parcialmente construido que nace como prototipo y se integra al sistema como interfaz:
  • Muestra el estilo y apariencia.
  • Simula funcionalidad con interactividad real entre las partes.
  • Considera llegar a una implementación con funcionalidad completa.

El prototipo resultante ha de probarse haciendo las modificaciones necesarias. Los resultados deben registrarse desde la revisión de los bosquejos y wireframes, hasta su integración al desarrollo.

Ventajas de prototipar:

  • Reducción del riesgo de construir productos diferentes a lo que el usuario espera.
  • Aumento de la probabilidad de éxito y fiabilidad.
  • Exige disponer de las herramientas adecuadas desde la planeación.
  • Se tiene un punto de unión de los involucrados en el desarrollo.
  • Aporte de seguridad en la eficacia de algoritmos por plantear e implementar.
  • Prueba directa en dispositivos y plataformas.
  • Se evita duplicidad de esfuerzos en el desarrollo al contar con un modelo que se puede integrar como frontend.
  • Probar con datos y contenidos reales.

Riesgos a evitar:

  • Pretender que el sistema se desarrolle basándose en el prototipo y no que el prototipo se integre al sistema
  • Permitir que el cliente considere que ve el producto terminado o que falta poco para ser entregado
  • Que el mantenimiento a futuro esté amenazado por un diseño pobre y recursos inadecuados
  • Utilizar datos, menús y volúmenes de información alejados de lo que finalmente se usará.
  • Que el prototipo se convierta en “la única verdad”, pues hay cosas que a veces no se contemplan en él.

Generar prototipos trae varios beneficios, pues es útil en la implementación al brindar una referencia que ayuda a los desarrolladores a entender los alcances del sistema, para dar un cálculo de tiempo más aproximado y realista del tiempo que tomará el proyecto. Para los responsables del proyecto es un auxiliar que les ayuda a darse a entender con claridad y fidelidad al momento de comunicarse con el equipo y el cliente.

Desde la presentación de las primeras ideas de interfaz, es necesario plantear una jerarquía de elementos que dan apariencia a una pantalla. El usuario necesita tener con evidencia algo que le permita resolver una tarea, diferenciando lo más importante de lo menos importante y sus interacciones. Como es notorio, la intención es obtener una representación aproximada, progresiva y escalable de la vista del sistema que servirá de interfaz para el usuario final.

Es de suma importancia que desde la especificación de requerimientos se refleje de forma completa, idónea y sin ambigüedad, lo que la interfaz de usuario debe aportar en la implementación de los comportamientos esperados del sistema, pues la razón de ser de un prototipo es reducir los tiempos de construcción y contribuir al aseguramiento de la calidad.

Especificación de los requerimientos

Anexo 4. Historia de usuario

Instructivo de llenado:

  • Nombre de la historia de usuario. Nombre corto para identificar fácilmente la historia de usuario.
  • Id. Clave que identificará de manera única la historia de usuario
  • Prioridad. Indica la prioridad que tiene la historia de usuario respecto a las otras historias de usuario. Inicialmente se puede asignar un valor de alto, medio, bajo y muy bajo para poder agrupar las historias de usuario. Sin embargo, lo más recomendable es que se les asigne un valor numérico y que todas las historias de usuario tengan una prioridad diferente, es decir, no pueden existir dos historias de usuario con la misma prioridad. Ayuda a determinar el orden en que deben ser implementadas.
  • Descripción. Descripción sintetizada de la historia de usuario. El estilo puede ser libre, según mejor nos funcione, debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio?

  • Criterios de aceptación. Sirve para establecer las características y pruebas que debe cumplir el producto para considerar que puede ser aceptado, con la finalidad de dar por finalizada su implementación. Los criterios de aceptación deben ser consensuados con el cliente.
  • Prototipo. Imagen del prototipo que ilustre la historia de usuario en caso de existir alguno.

Ejemplo de tabla de validaciones de la historia de usuario:

Rubro Definición Requerido Longitud Validación Mensajes de validaciones
Clave de usuario Identificador que se utilizará para ingresar a la administración S Mín 5 Máx 20 Verifica que sea único *obligatorio *único
Nombre (s) Se refiere al nombre o nombres del propietario de la cuenta S Mín 3 Máx 50   *obligatorio *alfabético
Primer apellido Se refiere al primer apellido del propietario de la cuenta S Mín 3 Máx 50   *obligatorio *Alfabético
Segundo apellido Se refiere al segundo apellido del propietario de la cuenta N Mín 3 Máx 50   *Alfabético
Cuenta de correo UNAM Se refiere a la cuenta de correo con dominio comunidad.unam.mx o unam.mx S Mín 9 Máx 100 Verifica que sea único y pertenezca al dominio .unam.mx *obligatorio *correo UNAM
Contraseña Se refiere a la contraseña que utilizará el usuario para ingresar a la administración S Mín 18 Máx 15 Verifica que la Contraseña contenga entre 8 y 13 caracteres e incluir al menos una letra, un caracter numérico, un caracter especial *obligatorio *contraseña *formato
Confirmar contraseña Reingresar la contraseña elegida por el usuario S Mín 18 Máx 15 Verifica que ambas contraseñas ingresadas coincidan. *obligatorio *contraseña Confirmación *formato

Ejemplo de tabla de validaciones de la historia de usuario Registrar nuevo administrador

Ejemplo de mensajes de validación de la historia de usuario Registrar nuevo administrador:

Ejemplo de tabla de mensajes de validación de la historia de usuario Registrar nuevo administrador

Anexo 5. Caso de uso

Instructivo de llenado:

  • Caso de Uso. Nombre del caso de uso.
  • Id. del CU. Clave que identifica de forma única el caso de uso.
  • Estado. Estado en el que se encuentra actualmente el caso de uso.
  • Actores participantes. Rol de algún usuario, dispositivo o sistema que interactúa con un sistema, utilizando la funcionalidad descrita en el caso de uso.
  • Breve descripción. Descripción resumida y general acerca de la funcionalidad esperada del caso de uso.
  • Pre-condiciones. Condiciones que se necesitan cumplir antes de que se pueda iniciar la ejecución de la funcionalidad especificada en el caso de uso.
  • Flujo principal. Es un flujo de eventos normal o camino feliz contenido en el caso de uso. Describe una secuencia de acciones que corresponden a la forma más simple de llegar al objetivo (Jacobson, 2013).
  • Flujos Alternos. Los caminos adicionales al flujo básico descritos en el flujo principal se describen en el flujo alterno. Contiene la descripción de un comportamiento variante u opcional como parte de la narrativa de un caso de uso. Los flujos alternativos se definen relativos al flujo básico del caso de uso (Jacobson, 2013).
  • Flujos de Excepción. Describe excepciones del flujo básico. Por ejemplo, Id del usuario incorrecto.
  • Post-condiciones. Condiciones o estados del sistema que se deben cumplir al finalizar la ejecución de la funcionalidad contenida en el caso de uso.
  • Notas. Notas técnicas, observaciones adicionales, requisitos no funcionales o información adicional que pudiera ser relevante para la implementación del caso de uso y que no se encuentra descrita en el flujo del mismo.

Ejemplo:

<img :src="$withBase('/img/DS/Anexos/ejemploCU1.png')" <img :src="$withBase('/img/DS/Anexos/ejemploCU2.png')"

Control de los cambios en los requerimientos

Anexo 6. Formato de Solicitud de ajuste

Instructivo de llenado:

  • Número de solicitud. Anotar el número consecutivo del ajuste solicitado.
  • Fecha de solicitud. Indicar la fecha en la que se está solicitando el ajuste.
  • Descripción del ajuste. Describir la funcionalidad que se debe implementar.
  • Justificación. Indicar: ¿Cuál es el motivo por el que se solicita la funcionalidad? (incluyendo si los usuarios lo están solicitando), ¿Qué se pretende solucionar o cubrir con esta funcionalidad?, ¿Qué usuarios utilizarán la nueva funcionalidad?
  • Resultado esperado. ¿Cuáles son los beneficios que se visualiza se obtendrán con esta funcionalidad?
  • Criterio de aceptación. Listar las características con que debería contar el producto que permitirían comprobar que la funcionalidad está desarrollada adecuadamente.
  • Secciones / Módulos afectados. Definir para qué partes del sistema aplica el ajuste solicitado (secciones, módulos, apartados, otros
  • Información adicional. Agregar información que a su consideración sea relevante para implementar el ajuste solicitado. Ejemplos de información de ese tipo pueden ser los volúmenes de información con que se cuenta, o bien, si existe alguna interacción con algún otro sistema que esté relacionada con la funcionalidad a ajustar.
  • Solicitado por. Nombre de quién solicita el ajuste.
  • Firma. Firma de quién solicita el ajuste.
  • Elementos que impactan (componentes y documentación). Listar los elementos que se tendrán que adecuar derivado de la implementación del ajuste solicitado especificando de qué manera sufrirán cambios dichos elementos y determine su nivel de impacto.
  • Requerimientos de implementación. Especificar y describir las líneas de acción que serán necesarios realizar para lograr una correcta liberación del ajuste a producción.
  • Evaluado por. Nombre del líder del proyecto de desarrollo a cargo.
  • Firma. Firma del líder de desarrollo.
  • Fecha de resolución. Fecha en que se da una resolución acerca de la implementación del ajuste.
  • Resolución. Respuesta a la solicitud de implementación del ajuste.

Ejemplo:

Diseño de base de datos

Anexo 7. Definición del modelo de datos

Para contar con las convenciones de la base de datos se presenta una guía para homogeneizar los modelos de base de datos creados. Es importante destacar que el objetivo principal de establecer estas convenciones de nombrado (además de la estandarización) es mejorar la legibilidad de los modelos de datos para contribuir al entendimiento del mismo. Esto beneficia al diseñador de software, programador, ingeniero de requerimientos y probador que deba comprender, utilizar, modificar o documentar la estructura de una base de datos.

Nombrado de tablas

  1. El punto importante es nombrar las tablas de tal forma que su lectura contribuya a entender el modelo de datos.
  2. El nombre de la tabla es un clasificador expresado en singular y debe denotar el tipo de registros que guarda o bien, la relación que representa para el caso de las tablas transitivas.

Ejemplos: “usuario”, “ficha”, “rol”, “entidad_federativa”, “usuario_rol”

  1. El nombre de la tabla se escribe en minúsculas.
  2. El nombre de la tabla debe ser pronunciable. Debería ser posible referirse al nombre de una tabla en una conversación sin tener que deletrear.
  3. Al nombrar tablas, evita abreviaturas o acrónimos ajenos al vocabulario del sistema al que pertenece la base de datos.
  4. El nombre de la tabla puede estar compuesto por una o más palabras unidas por un guión bajo.

Ejemplos: “entidad_federativa”, “municipio”, “localidad”

  1. Los nombres de tablas transitivas deben iniciar por la entidad principal en la relación. Ejemplos: “entidad_municipio”, “usuario_entidad_rol”

Esto permite que al consultar la lista de tablas, ordenadas alfabéticamente, las tablas se encuentren agrupadas por concepto o entidad principal.

Incorrecto Correcto
fototeca fototeca
autor_fototeca fototeca_autor
serie_fototeca fototeca_serie
  1. Evita nombrar las tablas con palabras reservadas del manejador de bases de datos o de lenguajes de programación.
  2. Evita nombres demasiado largos y toma en cuenta los límites máximos de caracteres de cada manejador de base de datos.
  3. Considera que los alias que se utilizan en las sentencias SQL también están sujetos al límite de caracteres de cada manejador y que varios frameworks de desarrollo concatenan el nombre de la tabla y el nombre de la columna para generar los alias.
  4. Evita nombres demasiado cortos que resulten confusos o ambiguos. Son aceptables nombres cortos que sean generalmente aceptables o que sean conocidos en el vocabulario del sistema. Por ejemplo “log”. Ejemplos de nombres cortos poco significativos: “i”, “cfg”, “xyz”

Nombrado de columnas

  1. El nombre de la columna debe representar la característica o atributo que se almacena en el contexto de la tabla.

  2. El nombre de la columna debe expresarse en singular.

  3. El nombre de la columna debe escribirse en minúsculas.

  4. El nombre de la columna puede estar compuesto por una o más palabras unidas por un guión bajo. Ejemplos: “nombre”, “primer_apellido”, “fecha_inicio”

  5. El nombre de la columna debe ser pronunciable. Debería ser posible referirse al nombre de una columna en una conversación sin tener que deletrear.

  6. Evita el uso de abreviaturas o acrónimos que sean ajenos al vocabulario del sistema al que pertenece la base de datos. Ejemplos: primer_ap, f_nacimiento, fecha_nac, fec_nac, fec_ini, fec_i, ent_acad

  7. Las excepciones al uso de abreviaturas son aquellos nombres que generalmente son aceptados como “id”, el cual es ampliamente utilizado como para denotar el identificador único de un registro y es más corto y legible que la palabra completa “identificador”.

  8. Evita el uso de prefijos que denoten el nombre de la tabla al que pertenece la columna. El nombre de la tabla debe ser contexto suficiente para entender el propósito de una columna.

Ejemplos:

Incorrecto Correcto
usr_primer_apellido primer_apellido
usr_nombre nombre
  1. Evita el uso de prefijos o sufijos que representen el tipo de dato que guarda la columna. El nombre elegido debería ser suficiente para entender el dominio de valores para la columna.

Ejemplos:

Incorrecto Correcto
by_file_size file_size
rgb_background background_color
bool_estatus estatus
dec_total total
  1. Los identificadores o llaves primarias únicos se nombran uniendo “id” con el nombre de la tabla con un guión bajo, de acuerdo al siguiente patrón: id_nombre_tabla

Ejemplos:

El campo “id_usuario” es el identificador único en la tabla “usuario” El campo “id_rol” es el identificador único en la tabla “rol”

  1. Las llaves foráneas se nombran utilizando el nombre de la llave a la que hace referencia. De manera opcional, en los casos donde se requiera puede agregarse un sufijo para especificar a qué se refiere el valor que representa la llave.

Ejemplos:

a) En la tabla “ficha” el campo “id_entidad_federativa” hace referencia a la llave primaria de la tabla “entidad_federativa”, la cual también se llama “id_entidad_federativa”.

b) En la tabla “ficha”, el campo “id_usuario_captura” hace referencia a la llave primaria de la tabla “usuario”, el sufijo “captura” sirve para especificar que ese campo almacena el id del usuario que capturó el registro.

c) En la tabla “ficha”, el campo “id_usuario_asignado” hace referencia a la llave primaria de la tabla “usuario”, el sufijo “asignado” sirve para especificar que ese campo almacena el id del usuario que tiene asignado el registro.

Nombrado y definición de vistas [Definir el nombrado o generación de alias para distinguir campos de diferentes tablas que tengan el mismo nombre.]

Por ejemplo, Select * from usuario, usuario_rol, rol (usuario y rol tienen campo nombre)

Planificación de las pruebas

Anexo 8. Tipos de pruebas

Entre la gran variedad de pruebas que se pueden realizar dependiendo de las necesidades del proyecto, se encuentran:

Tabla 1. Tipos de pruebas. Elaboración propia basado en el esquema ISTQB Certified Tester Foundation Level, pp. 109-130.

Clasificación:

Funcionales

Se prueban las funciones del sistema de acuerdo con lo descrito en las especificaciones de requerimientos como pueden ser casos de uso, historias de usuario, reglas de negocio, procesos, por mencionar algunos. Se basa en las entradas, la funcionalidad y las salidas observables al usar el sistema.

No funcionales

Se centra en probar:

  • Carga. Determinar la carga que puede soportar el sistema, por ejemplo, número de usuarios concurrentes y/o número de transacciones.
  • Estrés. Evaluar más allá de los límites especificados en los requisitos.
  • Performance (Desempeño). Determinar el rendimiento de un elemento bajo un determinado tiempo, considerando la capacidad de recursos disponibles o condiciones de acuerdo con los requerimientos especificados, un ejemplo puede ser: “La solución de software debe permitir registrar 500 alumnos en un periodo de 10 minutos”.
  • Mantenibilidad. Evaluar el esfuerzo requerido (facilidad) para realizar pruebas al sistema después de haber sido modificado.
  • Robustez. Evaluar el grado en el que el sistema puede funcionar correctamente al soportar entradas no válidas o condiciones de entorno de estrés. En este sentido se verifican los mecanismos de excepción.
  • Volumen. Probar grandes volúmenes de datos.
  • Usabilidad. Determinar si el software es comprensible, fácil de aprender y operar, atractivo a los usuarios.

Pruebas estructurales

El desarrollador prueba la estructura del programa usando técnicas de caja blanca evaluando la cobertura del programa. Suele realizarse análisis estático en el código mediante el análisis de flujo de datos, análisis de flujo de control o complejidad ciclomática y utilizando alguna de las técnicas: cobertura de sentencia, cobertura de decisión o rama o cobertura de camino.

Pruebas de aceptación de usuario.

El usuario o cliente verifica que el sistema funcione adecuadamente para su posterior puesta en producción. Pruebas de operación. El administrador verifica la instalación, respaldo, restauración, gestión de usuarios, recuperación de desastres, carga de datos, migraciones, por mencionar algunos.

Pruebas de aceptación contractual y normativas.

El usuario valida que el software cumple con los requisitos definidos en el contrato o que deba cumplir con alguna normatividad aplicable.

Pruebas Alfa y Beta.

El usuario realiza pruebas antes de que el software sea liberado en ambiente de producción con la finalidad de obtener la aceptación.

  • Alfa. Solo participa un número determinado de usuarios en un ambiente controlado.
  • Beta. Participan los usuarios o clientes potenciales en su propio ambiente.

Aplicación de las pruebas

Anexo 9. Reporte de incidencia

Se sugiere que el reporte de la incidencia contenga al menos los datos presentados en la plantilla:

ID Descripción Pasos Evidencias Notas Estatus
           
           

Instructivo de llenado:

  • ID. Clave que identifica de manera única la incidencia detectada.
  • Descripción: Breve descripción de la incidencia.
  • Pasos. Secuencia de pasos realizados en el sistema para detectar la incidencia y que permiten repetir la generación de la misma, por ejemplo, con qué perfil de usuario se ingresó al sistema, que actividades se ejecutaron, qué datos se ingresaron, entre otros.
  • Evidencias. Imágenes, videos y/o archivos que demuestran la incidencia detectada y ayudan al entendimiento del problema, así como a repetir la generación del error.
  • Notas. Datos adicionales que pudieran ayudar a dar seguimiento a la incidencia.
  • Estatus. Estado que tiene la incidencia, por ejemplo: Abierta, En corrección, Corregida, Cerrada, entre otros.

Ejemplo:

Herramientas

Lista de herramientas que se mencionan en este documento y sus sitios oficiales.

Nombre URL
Atom https://atom.io/
Bizagi https://www.bizagi.com/es
Bonita https://es.bonitasoft.com/
Bugzilla https://www.bugzilla.org/
DBeaver https://dbeaver.io/
Draw.io https://app.diagrams.net/
Eclipse https://www.eclipse.org/
Flyway DB https://flywaydb.org/
Github https://github.com/
Gitlab https://about.gitlab.com/
Jamboard de Google https://jamboard.google.com/
Jmeter https://jmeter.apache.org/
Justinmind https://www.justinmind.com/
Liquibase https://www.liquibase.org/
Lucidchart https://www.lucidchart.com/pages/es
Mantis https://www.mantisbt.org/
Marvel https://marvelapp.com/
Netbeans  
Selenium https://www.selenium.dev/
SonarQube https://www.sonarqube.org/
StarUML https://staruml.io/
Subversion https://subversion.apache.org/
Visual Studio Code https://code.visualstudio.com/
WebLoad https://www.radview.com/

Glosario

Actualización de software. Acto de cambiar o modificar una aplicación por una versión más actual de la misma.

Atributo de calidad. Es una característica no funcional que se considera como deseable en un producto de software.

Bases de datos. Conjunto ordenado de datos personales referentes a una persona física identificada o identificable, condicionados a criterios determinados, con independencia de la forma o modalidad de su creación, tipo de soporte, procesamiento, almacenamiento y organización.

Dato. Unidad mínima de información (números, letras o símbolos) que representa un objeto, condición o situación y que requiere una interpretación para convertirse en información.

Estándares abiertos. Las especificaciones cuya utilización esté disponible de manera gratuita o que no suponga una dificultad de acceso, y que su uso y aplicación no esté condicionada al pago de un derecho de propiedad intelectual o industrial (Glosario de la Guía Técnica de Interoperabilidad).

IEEE. Instituto de Ingenieros Eléctricos y Electrónicos. Es una organización internacional cuya misión es promover la innovación tecnológica en beneficio de la humanidad. Es una organización de profesionales dedicada a la creación de estándares internacionales en diversas áreas.

Información. La información que se genera u obtiene de manera impresa o escrita en papel, almacenada electrónicamente, recibida o transmitida por correo o por medios electrónicos, mostrada en video o hablada en conversación, que puede ser pública, reservada o confidencial y que se procesa o conserva en ejercicio de las facultades, funciones y competencias de las áreas universitarias.

Mantenimiento de software. En ingeniería del software, el mantenimiento de software es la modificación de un producto de software después de la entrega, para corregir errores, mejorar el rendimiento, u otros atributos. El mantenimiento del software es una de las actividades más comunes en la ingeniería de software.

Plataforma tecnológica. Es el software y hardware que permite ejecutar determinados módulos de una solución informática con los que existe compatibilidad.

Producto de software. Se refiere al sistema (código fuente), documentación asociada y datos necesarios para el funcionamiento del software que se desarrolló y que se entrega a un cliente o usuario.

Pruebas. Proceso de analizar un componente de software u operar un sistema que ayuda a detectar errores o defectos y a identificar la completitud o diferencias con respecto a los requerimientos y acuerdos establecidos con la finalidad de evaluar la calidad del software.

Requerimiento. Condición o capacidad que debe cumplir o poseer un sistema, componente del sistema, producto o servicio para satisfacer un acuerdo, estándar, especificación u otros documentos impuestos formalmente [IEEE 730-2014].

Requerimientos funcionales. Son declaraciones de los servicios o funciones que proveerá el sistema, de la manera que éste reaccionará a entradas particulares y de cómo se comportará en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo de estándares, así como los criterios de calidad requeridos.

Seguridad de la información. La capacidad de preservar la confidencialidad, integridad y disponibilidad de la información, así como la autenticidad, confiabilidad, trazabilidad y no repudio de la misma. (MAAGTICSI, 2016).

Sistema de información. Conjunto de aplicaciones, servicios, activos de tecnología de la información u otros componentes que manejan información (Glosario ISO 27001:2013).

Software. Programas de computadora, instrucciones o procedimientos que se ejecutan para operar y satisfacer las necesidades específicas de un usuario.

Software a la medida. Es aquel software que se diseña y desarrolla de acuerdo con los requerimientos específicos y forma de trabajar de una entidad o dependencia.

Usuario. Es aquella persona que utiliza determinado hardware y/o software, mediante el cual obtiene un servicio.

Usabilidad. La facilidad mediante la cual una aplicación, producto o servicio de TI puede usarse. Los requerimientos de uso se incluyen a menudo en una especificación de requerimientos.

Referencias

Materiales de cursos

  • Curso de Certificación en Análisis de Negocios. (2012). Kryteria it training & mentoring.
  • ISTQB Certified Tester Foundation Level. Training Based on ISTQB Syllabus 2011 Versión 1.0. Testing IT.

Créditos

Dr. Enrique Luis Graue Wiechers
Rector

Dra. Patricia Dolores Dávila Aranda
Secretaria de Desarrollo Institucional

Dr. Héctor Benítez Pérez
Director General de Cómputo y de Tecnologías de Información y Comunicación

Elaboración

Dirección General de Cómputo y de Tecnologías de Información y Comunicación

Luis Daniel Barajas González
Susana Laura Corona Correa
Karla Alejandra Fonseca Márquez
Leticia Martínez Calixto
Hugo Germán Martínez Cuéllar
Luz María Ramírez Romero
Hugo Alonso Reyes Herrera
Ana Berenice Rodríguez Lorenzo
María de los Angeles Sánchez Zarazúa
Edgar Vargas Zermeño

Revisión

Red de Responsables TIC, Grupo Desarrollo de Soluciones de Software