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

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:

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:

1. Enfocarse en las siguientes preguntas:
   • ¿Qué necesitas?
   • ¿Para qué lo necesitas?
   • ¿Cómo lo necesitas?
2. Definir objetivos específicos para la sesiones.
3. Establecer un límite de tiempo para la sesión.
4. Distribuir con anticipación la agenda con los involucrados.
5. Derivado de las reuniones establecer acuerdos y fechas de entrega.

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:

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.

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:

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:

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:

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

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:

4. Desarrollo de componentes reutilizables

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

• 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:

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.

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.

​

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.

2. 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:

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”

3. El nombre de la tabla se escribe en minúsculas.
4. 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.
5. Al nombrar tablas, evita abreviaturas o acrónimos ajenos al vocabulario del sistema al que pertenece la base de datos.
6. 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”

7. 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

8. Evita nombrar las tablas con palabras reservadas del manejador de bases de datos o de lenguajes de programación.
9. Evita nombres demasiado largos y toma en cuenta los límites máximos de caracteres de cada manejador de base de datos.
10. 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.
11. 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

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

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

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

14. 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”

15. 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.

16. 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

17. 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”.

18. 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

19. 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

20. 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”

​

21. 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:

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

• Bayse, Gail. (2004). A Security Checklist for Web Application Design. Recuperado el 26 de mayo de 2021 de https://www.sans.org/reading-room/whitepapers/securecode/security-check….
• Bolaños, Daniel. Et. al. (2007). Pruebas de Software y JUnit: un análisis en profundidad y ejemplos prácticos. España, Person Education-Addison Wesley, 322 pp.
• Coleman, B., Goodwin, D. (2017). Designing UX: Prototyping, E.E.U.U., SitePoint.
• García, José. (2014). Diseño de elementos software con tecnologías basadas en componentes. ProQuest Ebook Central. Recuperado el 26 de mayo de 2021, de http://ebookcentral.proquest.com/lib/bibliodgbsp/detail.action?docID=44….
• Dirección General de Cómputo y de Tecnologías de Información y Comunicación. (2018). Guía de recomendaciones para la evaluación y selección de soluciones de software. Recuperado el 19 de mayo de 2021 de https://www.red-tic.unam.mx/recursos/DCV_GuiaEvaluacionSeleccionSolucio…
• Jacobson, Ivar. (2013). CASOS DE USO 2.0. La guía para ser exitoso con los casos de uso. Recuperado el 26 de mayo de 2021, de https://www.ivarjacobson.com/sites/default/files/field_iji_file/article…
• Kruchten, Philippe. (1995). The 4+1 view model of software architecture. E.E.U.U. IEEE Software 12 (6), pp. 42-50.
• P. Bourque and R.E. Fairley, eds. (2014). Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society. Recuperado el 26 de mayo de 2021 de www.swebok.org
• Sichen, Meng. (2010). The “4+1” view model on safe home system architecture. , E.E.U.U., Conference Proceedings: 2010 IEEE International Conference on Software Engineering and Service Sciences.
• Sommerville, Ian. (2011). Ingeniería de software. México, novena edición, Person Education-Addison Wesley, 792 pp.
• Yau, Stephen. (1986). A survey of software design techniques. E.E.U.U. IEEE transactions on software engineering, vol. se-12, no.6. Estándares
• Institute of Electrical and Electronics Engineers. (1998). Recommended Practice for Software Requirements Specifications (IEEE 830). Reaffirmed 9 December 2009. https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/720574
• Institute of Electrical and Electronics Engineers. (2012). Standard for Configuration Management in Systems and Software Engineering. (IEEE 828). https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/6170935
• Institute of Electrical and Electronics Engineers. (2013). Software and systems engineering --Software testing --Part 1: Concepts and definitions (ISO/IEC/IEEE 29119-1). https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/6588537
• Institute of Electrical and Electronics Engineers. (2013). Software and systems engineering --Software testing --Part 2: Test processes (ISO/IEC/IEEE 29119-2). https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/6588543
• Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering - Requirements for acquirers and suppliers of information for users (ISO/IEC/IEEE 26512). https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/8288807
• Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering - Vocabulary (ISO/IEC/IEEE 24765). https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/8288807

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