This video discusses the process of obtaining software system requirements, highlighting its difficulty and the factors that complicate it. It also introduces Business Process Management (BPM) notation as a tool for modeling and analyzing organizational processes, explaining its components and providing examples of its application.
La obtención de los requerimientos de un sistema de software es un proceso crucial y desafiante. Para que sea preciso, debemos saber exactamente qué se va a construir. Sin embargo, existen factores que imposibilitan la obtención correcta de estos requerimientos.
Visto desde una perspectiva de "caja negra", donde hay entradas y salidas, el objetivo es producir un modelo o documento de requerimientos que se traducirá en código para solucionar un problema. Las entradas para este proceso suelen ser sistemas de información ya existentes en la organización, que no se desechan sino que trabajan en paralelo con los nuevos sistemas. Estos sistemas antiguos pueden proveer información valiosa para el nuevo sistema.
Además, la necesidad de los "stakeholders" (personas interesadas en la organización que no son necesariamente empleados) es fundamental. Ellos también necesitan conocer la situación de la organización y aportan sus puntos de vista sobre qué sistemas les ayudarían a tomar decisiones.
La comprensión del dominio, es decir, el conocimiento profundo del área o las áreas donde se trabajará, incluyendo sus conceptos y clases, es esencial para el proceso de ingeniería de requerimientos.
La obtención de requerimientos no es tarea fácil debido a varios factores:
Estos factores humanos interactúan y complican la obtención de requerimientos, que es una actividad inherentemente humana. La simpatía y la forma de comunicación entre personas también influyen.
El proceso básico involucra a clientes/usuarios y desarrolladores que interactúan, a menudo a través de reuniones y conversaciones, para obtener los requerimientos.
Una vez obtenidos, los requerimientos se capturan. Esto define los actores o roles que intervendrán en el sistema y las funcionalidades que ofrecerá (el menú o árbol de solución del software).
Al redactar los requerimientos, se deben seguir ciertas pautas:
Ejemplos de requerimientos:
Otro ejemplo de requerimientos mal redactados:
Estos requerimientos son ambiguos porque carecen de métricas claras.
Ejemplos de requerimientos mejor redactados (con métricas):
Siempre debe haber una métrica o meta para validar si un requerimiento se cumple o no.
Los procesos que se realizan se conceptualizan como un conjunto de actividades que se repiten, mientras que un proyecto es un conjunto único de actividades que entregan un resultado. Los procesos siempre deben aumentar o mantener el valor.
Cuando interviene la informática, los procesos tienden a acortarse y se les debe dar un valor agregado. Cada vez que se rediseñan o se informatizan, los procesos cambian para mejorar.
Para modelar estos cambios, se utiliza la notación BPM (Business Process Management). Existen herramientas como Visio (de Microsoft) y Process Maker que ayudan a diagramar estos procesos.
El modelado de procesos dentro de una organización implica verificar:
Cada vez que se informatiza o se crea un nuevo software, todos los procesos de la organización se ven afectados y deben ser modificados.
La jerarquía para validar o procesar información de actividades incluye:
Este es un mapa para realizar un análisis o cambio de procesos. Un simple mapeo (dibujo del proceso) es un primer paso. Luego se puede documentar, diseñar, estudiar con otros para mejorar la eficiencia y, finalmente, rediseñar el proceso (reingeniería de procesos), transformándolo de manual a informatizado.
En la notación BPM, se utilizan:
Un ejemplo de proceso en notación BPM es el de "compras", que incluye un punto de inicio, un punto final y una serie de actividades. Otro ejemplo es el de "boletos aéreos", donde intervienen el cliente, el agente de viajes y la agencia de viajes, mostrando cómo fluyen las actividades y las interacciones entre ellos.
Esta notación BPM puede ser más sencilla de compartir con usuarios que una anotación UML. Los procesos también pueden ser modelados con UML, lo cual se verá en temas posteriores.
Existen diversas formas de diagramar procesos, y la notación BPM es una de ellas, junto con UML.
[Música] i buen día vamos a continuar con nuestro tema de la obtención de los requerimientos de un sistema de software. hemos hablado que el proceso de ingeniería de requerimientos debe de ser algo preciso, es decir, debemos de saber con exactitud qué es lo que se ve o qué es lo que se va a construir dentro de lo que es el sistema. por lo tanto, esa es la tarea más difícil: decidir qué se va a construir, ya que existen ciertos factores que pueden imposibilitar la obtención correcta de los requerimientos para el sistema. la obtención de los requerimientos, visto desde el punto de una caja negra, por así decirlo, donde tenemos factores de entrada y pues al final lo que necesitamos, o un modelo o un documento de requerimientos que van a ser codificados dentro de un lenguaje para dar la solución que se está pidiendo. en el cual, pues, como entradas normalmente, pues vamos a tener sistemas de información que ya se encuentran dentro de lo que es la organización, perdón, y que brindan información. normalmente estos sistemas no se desechan, sino que continúan trabajando a la par de los sistemas que recién se crean. estos probablemente van a proveer de cierta información para nuestro nuevo sistema. también la necesidad de los stakeholders, es decir, personas o sea que tienen mucho que ver con la organización y que no son trabajadores propiamente dichos de la organización, verdad. entonces, también ellos necesitan saber la situación de la organización y ellos, por ser parte dinámica de la organización, entonces también dan sus puntos de vista sobre qué es lo que se debe de tener dentro de la organización como sistemas que les ayude a tomar decisiones. y como lo habíamos hablado, también la comprensión del dominio, es decir, conocer exactamente el área en el cual vamos a trabajar o las áreas en las cuales se van a trabajar. y pues conocer ese dominio, esas clases, esos conceptos, o sea, qué se manejan dentro de esas organizaciones, pues porque todo eso se mete a un proceso que es la ingeniería de requerimientos, que me permite dar el modelo de sistemas y cómo este va a operar en todo su entorno.
la obtención de estos requerimientos no es tarea fácil. existen ciertos factores, o sea, que hacen que esta tarea sea difícil. una de ellas, pues es la psicología cognitiva, en la cual, pues dependiendo de la cultura de la persona o de las personas en el departamento o la organización que lo vamos a hacer, entonces sea difícil poder transmitir ciertas necesidades de información, ya sea porque tienen miedo a perder cierto control o a creer que van a ser desplazados por una computadora, etcétera. entonces, ahí existe este tipo de psicología, en la cual, pues va a haber que lidiar contra estas personas, contra esta dificultad, verdad, para poder obtener lo mejor de ellos. otra cosa que dificulta enormemente la obtención de esos requerimientos es la parte antropológica, es decir, a muchas personas no les gusta que las observemos cuando ellos trabajan porque se sienten acosados, porque se sienten que se invade su espacio, etcétera. entonces es algo con lo cual también nosotros tenemos que lidiar. y quizás un aspecto bastante, bastante importante es la sociología, en la cual, pues la persona ha de decir, bueno, si yo no aprendo a programar o yo no aprendo sobre este sistema, me van a echar. entonces, por lo tanto, voy a dar cuestiones, o sea, que son falsas, etcétera. entonces existe esta serie de factores o de hechos que nos pueden, en un determinado momento, hacer difícil la obtención de los requerimientos por parte de los usuarios. por lo mismo, porque es una actividad humana y en la cual, pues interactúan personas y esa interacción, pues tiene que ver con muchos otros factores, no solamente estos que aparecen acá, sino que pues la simpatía que pueda tener una persona al comunicarse o la forma en cómo se comunica una persona con la otra, etcétera.
el proceso básicamente, pues tiene que ver con esto, ¿verdad?, donde pues tenemos a los clientes o los usuarios, los desarrolladores, que son los que se ponen en contacto, hacen reuniones, conversan y a partir de eso, pues obtienen los requerimientos. luego de que se obtiene estos requerimientos, pues vemos, o sea, cómo se capturan esos requerimientos. es decir, las pantallas sociales las cuales nosotros vamos a pedirle a los usuarios que visiten o capturen la información. esto, pues nos va a decir quiénes son los actores o los roles que van a intervenir dentro de lo que es el sistema y también nos provee las funcionalidades o las funciones, o sea, que vamos a tener del sistema, es decir, el menú o el árbol de solución de este software que estamos creando. entonces, esto es como cómo debemos nosotros de obtener estos requerimientos.
los requerimientos, una vez obtenidos, pues hay ciertos hechos que debemos de respetar. los requerimientos, pues van a ser especificados o redactados en un lenguaje natural, evitando, pues el glosario complicado o palabras complicadas que tienen mucho que ver con el dominio de las personas a las cuales vamos a hacer el sistema. entonces, habrá que, en la medida de lo posible, evitar ese tipo de palabras. estos requerimientos también deben de expresarse en forma individual, es decir, qué es lo que cada persona requiere. también va a haber que jerarquizar los, es decir, darles una prioridad. cuáles son más importantes que otros para comenzar a desarrollar los primeros, o sea, hay que existe la necesidad de que se deba de hacer un requerimiento antes que otros, porque este requerimiento va a hacer que este otro requerimiento sea más fácil de obtener, etcétera. entonces, hay ciertos factores que nos van a indicar a nosotros, o sea, una jerarquización, jerarquización, perdón, de estos requerimientos para posteriormente poder ser codificados dentro de un lenguaje de programación y un entorno de la empresa u organización en la cual estamos haciéndolo.
veamos algunos ejemplos de estos requerimientos. en este caso, pues es un requerimiento mal redactado. y lo que dice: "ok, para facilitar el uso de un editor gráfico, se podrá activar y desactivar una rejilla que permita alinear las figuras del diagrama o de un diagrama." "cuando se ajuste la figura al tamaño de la pantalla o al tamaño adecuado, se va a reducir el número de líneas de la rejilla para que no se dificulte la visualización de la misma." a primera vista, esto parece ser un requerimiento normal sin mayores problemas, pero realmente está mal redactado porque debe de ser medible. por ejemplo, este es una mejor redacción para ese requerimiento: "el editor permitirá el uso de una rejilla de líneas horizontales y verticales que aparecerán dibujadas tras el diagrama. hemos acotado el requerimiento, haciéndolo un poco más flexible, mejor comprensible para el usuario. por ejemplo, alguien que va a dibujar software que vamos a crear para dibujo."
este otro ejemplo de requerimiento mal redactado, o de requerimientos mal redactados, por ejemplo: "el sistema será lo más fácil de utilizar." "el sistema va a proporcionar a los usuarios una respuesta rápida." "el sistema se va a recuperar automáticamente tras producirse un fallo." y estos son requerimientos típicos que nosotros podemos encontrarlos en cualquier desarrollo del software y podríamos decir que están correctos. sin embargo, pues al momento de intentar validar los o que, como decimos que realmente el sistema es fácil de utilizar, cuál es la métrica que me va a dictar si se cumple o no se cumple este requerimiento.
ok, estos ya son unos requerimientos mejor redactados. por ejemplo: "un usuario experimentado debe ser capaz de utilizar todas las funciones del sistema tras un entrenamiento de dos horas, tras el cual, pues, no va a cometer en este caso tres errores." podemos decir dos errores, pero siempre tenemos que definir una métrica para poder decir si el requerimiento de válido o pasó el test o no pasó el test. luego el otro: "cuando haya X cantidad de usuarios, en este caso 100 usuarios, de forma concurrente al sistema, el tiempo de respuesta no debe de ser mayor a 2 segundos o 3 segundos o 5 segundos." siempre, como les menciono, debe de haber una métrica o una meta a la cual nosotros debemos apuntar para decidir si el requerimiento se cumple o no se cumple, es decir, dar por válido el sistema o no.
siempre dentro de este ámbito vamos a tener que considerar esto, que los procesos o sea, que vamos a estar realizando, van a ser o vamos a conceptualizar los como un conjunto de actividades que se repiten. también un proyecto es un conjunto único de actividades que entregan un resultado. y que los procesos siempre van a tener que aumentar un valor, o al menos mantener el valor, cada vez que nosotros necesitemos reformular un proceso. y que normalmente va a ser así, siempre, porque cuando interviene una máquina, los procesos se van a acortar. vamos a tener que darle un valor agregado a esa parte cada vez que nosotros lo estemos rediseñando. entonces, los procesos cada vez que entre la informática van a ser cambiados y ese cambio va a tener que ser para mejorar. cómo nosotros podemos observar este cambio, cómo podemos modelar este cambio, pues existe una anotación que se le denomina BPM, Business Process Manager, man. en el cual, pues es una forma de poder diagramar los procesos dentro de lo que es la organización. en este caso, pues existen varias herramientas o sea que pueden ser utilizadas para tal fin. es decir, nosotros hablamos con los usuarios, les preguntamos cómo son esos procesos, ¿verdad?, y luego venimos y diagramamos esos procesos. una vez los tenemos diagramados esos procesos, podemos decir, bueno, a esta actividad puede ser cambiada o puede ser juntado junto con esta, ¿verdad?, para poder acotar. herramientas que pueden utilizar para poder hacer estos diagramas utilizando la notación BPM es Visio, la empresa Microsoft Visio, que es una herramienta que posteriormente vamos a ver en un videotutorial de un uso de ella. y otro que pueden utilizar esos procesos, maker, también, que se utilizan mucho en la industria para modelar procesos.
básicamente en modelado de personal de procesos, o sea, dentro de una organización, tiene que ver con todo esto que tenemos que ir a verificar. cuáles son esas actividades, o sea, que se hacen. cuáles son los indicadores de que esa actividad sea correcta. el por qué, por qué vamos a cambiar ese proceso. cómo lo vamos a cambiar. con qué tecnología va a ser cambiada. esta actividad se va a unir con esta otra, o probablemente haya que separar la actividad para hacerlo, probablemente más eficiente. quién va a ser ese ese cambio, o quién va a ser ese proceso. puede ser una persona, las computadoras, y cualquier otra forma de poder interactuar con esos sistemas o con esos procesos. luego, cuándo, ¿verdad?, qué qué tiempos, o sea, hay que acotar los, o cuándo se debe realizar la actividad. en dónde, ¿verdad?, se van a realizar esas actividades. cuánto va a costar, ya sea aumentar su costo, va a disminuir su costo, o se va a mantener igual, ¿verdad? y qué otras posibilidades nosotros podemos tener de que ese proceso, pues se haga de manera diferente. entonces, normalmente esto es un proceso que nos vamos a involucrar bastante. de hecho, cada vez que se informatiza o se crea un nuevo software dentro la organización, todos los procesos van a ser tocados y todos los procesos van a tener que ser modificados de alguna forma.
más o menos esta es una jerarquía en la cual ustedes deben de basarse para validar o procesar esta información de las actividades. tenemos grupos de procesos y las, las herramientas también así lo lo trabaja, ¿verdad?, comenzando por grupo de procesos. luego definen los procesos, los procesos de reclutamiento de personal, por ejemplo, lo que entrevista, exámenes, etcétera. cuáles son los subprocesos, ¿verdad?, de la entre que son los exámenes, entrevistas que puedan hacerse. qué actividades hay. verdad, que hay un examen de inteligencia, un examen de capacidades, etcétera, etcétera. y luego, pues algunas tareas que puedan estar. cada una de esas actividades que son para cada proceso. este, ¿verdad?, es el mapa que ustedes pueden tener para cuando ustedes van a hacer un análisis o van a hacer el cambio de estos procesos. a medida ustedes a un análisis más profundo de esos procesos, ustedes pueden hacer, probablemente un cambio o dejarlos igual. es decir, si nosotros tenemos un proceso y simplemente, pues lo mapeamos, es decir, lo dibujamos, pues no estamos haciendo mucho más. sin embargo, pues es un paso que nosotros hemos hecho para hacer un cambio. en este caso, identificamos el proceso y lo documentamos. luego, pues podemos hacer un diseño de ese proceso. y, pues, podemos hacer un estudio junto con otras personas porque la parte de ingeniero de sistemas, pues no es una persona que esté hecha para hacer más eficientes los procesos, sino que va a tener que valerse de otras personas para mejorar la eficiencia de estos procesos. luego, pues, una vez detectadas las actividades que puedan ser cambiadas, pues redefinimos el proceso. y a ese nivel, pues está lo que se le llama la reingeniería del proceso, es decir, cambiamos totalmente un proceso, probable que sea manual a un proceso totalmente informatizado. entonces, esos son los cambios o sea, que pueden verse o se van a afectar, ¿verdad?, con la implementación de un sistema.
en la anotación BPM, ustedes van a tener estos tipos de herramientas o de artefactos dentro de lo que es la anotación. ustedes van a tener la dotación de flujo, donde van a expresar la semántica de modelado, cómo fluye, ¿verdad?, de un lado hacia otro, cómo se conecta. los andarrieles, también que se le llama, ¿verdad?, que son utilizados para agrupar elementos. y los artefactos, que básicamente se tienen ahí, que son utilizados como bien lo dice acá, para proveer información acerca del flujo y del, perdón, acerca de información del proceso para, y que no afecta el flujo, es decir, es como una descripción de lo que se puede estar o lo que se hace dentro de lo que es ese proceso. entonces, estas son los artefactos o las herramientas con las cuales ustedes cuentan en una anotación BPM para poder hacer ese modelado. este es un proceso sencillo en notación BPM, entonces, donde tenemos allá un punto de inicio y un punto de final. y ustedes pueden ver la serie de actividades de las cuales se compone este proceso, ya que es un proceso de compras. estas son las actividades que ustedes tienen, ¿verdad?, y los eventos de inicio y fin. entonces, a este tipo de herramientas son las que ustedes tienen acceso cuando utilizan una anotación BPM para modelar procesos.
los andarrieles, son figuras que ustedes van a utilizar para poder segmentar ciertas actividades. en este caso, un lane es una subdivisión del pool, ver el proceso completo, ¿verdad?, o sea, que ustedes tienen. y los ley van a hacer, pues como subprocesos o sea, que ustedes van a obtener de un proceso macro. por ejemplo, reclutamiento de personal, entrevistas y exámenes, por ejemplo, ¿no? entonces, eso es a lo cual se refiere en los andarrieles dentro de lo que es la anotación del BPM. aquí ustedes pueden ver un ejemplo un poco más completo, ya, de, pues, esto es un ejemplo que hemos venido viendo a través de diferentes videos. en este caso, tenemos un proceso de boletos aéreos de compra de boletos aéreos, donde intervienen tres personajes, ¿verdad?, del agente de viaje, la agencia de viajes propiamente dicho, y el cliente, donde, pues, el cliente, pues es quien comienza las actividades a preguntar si existe o no existe, ¿verdad?, un vuelo para tales y tales lugares, en tales condiciones, en tales fechas. entonces, y así se va haciendo la anotación hasta, pues, llegar a un punto de finalización del proceso. entonces, aquí estamos utilizando esa notación BPM para poder a verificar este proceso. quizá esta anotación, no sé, es un poco más sencilla compartirla con los usuarios porque están más inmersos en esta anotación que en una anotación de UML, como la que hemos visto también. estos procesos pueden ser modelados a través de UML, tal como lo vamos a ver más adelante en otro tema. cómo pueden ustedes apreciar, pues existen diversas formas en la cual ustedes pueden diagramar los procesos. la notación BPM les puede ayudar a esto, y la notación UML, que la veremos posterior, también lo hace. gracias por la atención prestada.
[Música] bien [Música]
