This video discusses the importance of requirements engineering in software development. It explains what requirements are, why they are crucial for project success, and the need for a flexible yet precise process to gather them. The video also touches upon the various stages and stakeholders involved in defining and validating these requirements, and introduces the concept of a conceptual model to understand the application's domain.
[Música] bien buen día vamos a continuar con nuestra temática orientada a objetos en esta ocasión vamos a hablar sobre las necesidades de información que se requieren dentro de la organización al momento de elaborar un software esta tarea tiene mucho que ver con algo a lo que nosotros le llamamos ingeniería de requerimientos o ere en sus abreviaciones normalmente el éxito o fracaso de un sistema funciona o no funciona bien depende básicamente de este proceso de ingeniería de requerimientos el cual es a través de diferentes etapas en las cuales se pregunta a los clientes cuáles son los servicios que ellos son los que requieren o los que se necesitan para poder voltear los dentro de un sistema de software el éxito de este trabajo se va a medir cuando el sistema cumpla con todos los objetivos que fueron planteados por los usuarios del sistema es de tener en cuenta este proceso se ve sometido a diferentes cambios debido a que dentro del proceso o dentro del software se pueden cometer diferentes errores ya sea de cálculos o algún error no contemplado dentro de lo que es el sistema por ejemplo una división entre cero y el sistema pudo haber fallado o alguna mejora que se tenga que hacer al sistema por lo tanto el proceso de la ingeniería de requerimientos debe de ser un proceso preciso y además flexible preciso porque debemos de determinar con exactitud qué es lo que realmente el cliente o el usuario final de la aplicación requiere y flexible porque probablemente tengamos definido el requerimiento pero por alguna razón probablemente fuera de la organización ajena a esta organización habrá que hacer un cambio en dichos requerimientos por lo tanto también el proceso debe de ser flexible y no encajo narros aunque si esa fue la solución primera que se dio no habrá que hacerle cambios no es cierto siempre va a haber necesidad de poder hacer cambios y por eso es que se requiere que este proceso de ingeniería de requerimiento sea flexible veamos algunos hechos que tienen que ver con este proceso de la necesidad de la información un requerimiento es una función que debe realizar el sistema o el software como tal alguna capacidad o atributos de calidad probablemente del sistema recordemos que hay atributos que son de información media y de atributos que no son de información estos atributos que no son de información son de calidad dentro de lo que es el sistema por ejemplo que dé una respuesta en menos de un tiempo determinado tres segundos por ejemplo estos factores de calidad afectan el desempeño del sistema es decir hacen que el sistema sea amigable al momento de estar utilizándolo estos criterios de calidad también van a afectar la forma en cómo los datos de entrada tienen que implementarse la premisa es que el usuario digital lo menos posible datos porque a medida que el usuario interactúa con el software y la probabilidad que se cometa un error al momento de digitar un dato es más alta por lo tanto pues habrá que pensar la forma en cómo vamos a implementar esta forma de entrar datos a lo que es el sistema para que luego tomemos esa información veamos como que se comporta en el mundo real y si hay que multiplicarlo si hay que dividirlos hay que sacar percentiles hay que poner gráficas etcétera etcétera y eso nos va a ayudar up poner de relieve el problema que ha sido resuelto con este sistema recordemos que pues los factores de calidad van a afectar el rendimiento de la aplicación y las necesidades de información básicamente indican el éxito o el fracaso de lo que es el uso del sistema por parte del usuario es decir que les sea útil no solamente que les sea fácil de usual sino que sea útil y los requerimientos básicamente se ven como se puede observar en la gráfica involucrados en todas las tareas que lleva el desarrollo del sistema por ejemplo cuando yo estoy utilizando el software esto me puede dar pie a que hayan nuevos requerimientos por ejemplo que haya una lista de datos que no necesita cambiarse y que por abe motivo nosotros dejamos una caja de texto libre para que el usuario lo pueda visitar entonces me puede retroalimentar para volver a obtener un nuevo requerimiento en este caso de calidad el diseño del producto básicamente también me puede llevar a retroalimentar pantallas colores forma de reportes etcétera y dentro del análisis del sistema igual ver dados a este es probable que haya un reporte y algunas gráficas que probablemente puedan obtenerse en un solo requerimiento y no tratarlos como requerimientos separados es por eso que el proceso de la ingeniería del software debe de en cierto momento parar cuando ya obtengo la información analizar si es realmente lo que se requiere o si un usuario está pidiendo un requerimiento que solamente varía en probablemente una o dos cantidades probablemente ese requerimiento pueda juntarse y proveer un nuevo requerimiento que quizás sirva mejor a la organización cuando recabamos las necesidades de la información para obtener los requerimientos del cliente básicamente hacemos cuatro etapas estas cuatro etapas deben de estar totalmente documentadas y si es posible obtener una firma de parte de los usuarios que nos han pedido hacer el sistema lo primero que nosotros debemos hacer como analistas es entender el problema es decir qué es lo que queremos resolverlo al cliente o al usuario final oa nuestra organización en ese sentido nosotros tenemos que hablar el idioma de la persona con la cual va a usar el sistema es decir si es alguien de recursos humanos pues vamos a tener que conocer la forma en cómo se habla en recursos humanos por el contrario si es algo de contabilidad o de finanzas pues vamos a tener que empaparnos de ese lenguaje que utilizan ellos para poder entender lo que se nos quiere decir y luego de nosotros haber entendido este problema no debemos de describirlo es decir debemos hacer las especificaciones que el software que se va a desarrollar una vez nosotros hemos documentado y hemos dicho el sistema va a tener que hacer estas funciones y estas otras funciones hay que hacer una validación realmente el usuario y esos requerimientos que me han sido dados son los apropiados para él realmente los quiere o los necesita para tomar una decisión muy probablemente nos topamos con organizaciones en las cuales hay un efecto de computar it is que todos quisieran tener los reportes de todos en ese sentido es cuando el analista del sistema verifica o valida junto con la persona de mayor rango dentro de la organización si realmente este requerimiento le es funcional para ese usuario luego de nosotros haber hecho esta validación tenemos que establecer los límites de lo en los cuales el sistema va a operar muy probablemente vamos a tener que considerar nuestro recurso humano nuestro recurso financiero nuestro recurso tiempo para decidir qué es lo que vamos a tomar en cuenta para el desarrollo de una primera aplicación y probablemente esto otro va a quedarse para una siguiente etapa como dije al principio esto debe de estar totalmente documentado y de ser posible con el visto bueno de los usuarios que se ven involucrados en este proceso algunos usuarios que se ven involucrados en este proceso son los siguientes como ustedes lo pueden apreciar en cada una de las fases por ejemplo cuando yo defino los requerimientos es decir cuando me lista que es lo que quieren normalmente pues es el gerente general el director los usuarios del sistema propiamente dichos los ingenieros que trabajan para la organización que definen ciertos requerimientos de información fue arquitecto del sistema ya los arquitectos de sistemas son aquellos que puedes prever hacia dónde va la tecnología y cómo esa tecnología puede apropiarse y utilizarse entre lo que es la organización también la especificación de los requerimientos es decir la validación de esos requerimientos que fueron definidos verdad entonces ya tenemos que hablarlo con los usuarios finales del sistema con los ingenieros propios del cliente los clientes o de la organización para cual estamos trabajando arquitectos del sistema propiamente dicho verdad y comenzamos a involucrar a los desarrolladores de software dentro de las especificaciones del software entonces ya ustedes tienen a ingenieros arquitectos de software y a los desarrolladores de los codificadores de la solución este es un modelo que más o menos se puede seguir con cada uno de los y diseños de reportes o de documentos o sea que deben de obtenerse por ejemplo en el estudio de factibilidad un reporte de factibilidad normally en este reporte pues vamos a tener una factibilidad operativa es decir sí existen las condiciones operativas dentro de la organización para poder implementar el sistema es decir nuestros usuarios finales saben utilizar la computadora bien o solamente saben ciertas cosas va a haber que capacitarlos o es una nueva tecnología a la que vamos a cambiar por ejemplo de un ambiente windows a un ambiente linux oa un ambiente mac ya sea tiene las capacidades para poder hacer ese cambio etcétera luego pues tenemos el análisis de requerimientos verdad modelos de sistema que es el que vamos a plantear en esta etapa es decir va a ser un sistema web va a ser un sistema de de stop o móvil ya eso lo definimos verdad luego pasamos a la siguiente etapa donde definimos propiamente los requerimientos y allí después ya nosotros hacemos una red de definición verdad de estas datos de entrada de estos requerimientos propiamente dichos verdad reportes de los usuarios para luego puedes pasar a la parte de especificación propiamente dicha de los requerimientos no es decir ya este es el formato del listado que se requiere o este es el formato del gráfico que se requiere o de las tablas que se requieren o del documento que se requiere general para generar dentro de lo que es la aplicación hay que tener en cuenta que un documento de requerimientos es una declaración oficial de lo que se requiere dentro de lo que es el sistema que se va a desarrollar es decir es como un check list de qué es lo que se nos va a evaluar al final de finalizado estudiar el software si cumple o no cumple cada uno de esos ítems que han sido detallados ahí también es una definición y especificación de los requerimientos está totalmente detallado qué es lo que se requiere el reporte de tal cosa el gráfico de tal cosa tener en cuenta también que un documento de requerimientos no es un documento de diseño un documento de diseño implica muchas más cosas es decir de definición de pantallas colores que van colores corporativos que puedan ser utilizados formatos etcétera el analista de requerimientos pues tiene que intercambiar ideas con muchas personas por ejemplo con los administradores del proyecto los cuales van a decir qué recursos tenemos o con cuáles recursos vamos a contar tiempo dinero personal con los desarrolladores que son con quienes quizás más comunicación van a tener ya que él les va a decir o va a validar si esa pantalla que ha sido codificada está bien o no está bien cumple o no cumple con los patrocinadores del proyecto o los stakeholders que se le llama verdad que muchas veces ellos también requieren cierta información de cómo se encuentra la organización de otros interesados como por ejemplo instituciones del gobierno que puedan interesarse en que algún reporte de pérdidas de ganancias de la empresa por ejemplo por ejemplo ministerio de hacienda o puede que se comparta cierta información constituciones como el seguro social etcétera qué problemas se ven asociados a la ingeniería de requerimientos oa la obtención de estas necesidades de información primero el alcance es decir hasta dónde vamos a llegar si el requerimiento pues puede ser demasiado corto o muy amplio verdad entonces eso va a ver que negociarlo hasta hasta dónde vamos a llegar o que tanto la información que se debe condensar en una página todas esas son cuestiones o sea que los vamos a tener que enfrentar la comprensión por ser diversas áreas del conocimiento en las cuales se trabaja recursos humanos contabilidad finanzas pues va a haber que meterse a ese tipo de lenguaje para realmente comprender o entender qué es lo que el usuario me está queriendo dar a entender igual nosotros no podemos hablarle en un lenguaje técnico a los usuarios porque no nos van a entender la volatilidad de los requerimientos como ya lo dije muchas veces hay factores externos a la organización en la cual vamos a tener que cambiar definitivamente en los requerimientos y se debe de hacerlo se debe de hacer porque de lo contrario el sistema no funciona también puede existir algún conflicto requerimientos dentro de los usuarios es decir a un usuario le interesa cierta información y también al otro usuario le interesa cierta información y a lo mejor es la misma pero no la quieren compartir y pues puede existir un conflicto verdad entre los usuarios y las necesidades de información que ellos puedan tener en el mundo de los requerimientos básicamente hay cuatro vistas o cuatro formas de verlo desde el mundo del usuario o sea como el usuario ve esos requerimientos verdad normally es la forma más fácil de verlo verdad yo quiero una yo quiero una plantilla de esto verdad quiero un informe de esto haciéndolo ver sumamente sencillo pues probablemente él está acostumbrado a hacer algo en papel y simplemente toma un lápiz y hacerles voz y probablemente lo hace muy rápido entonces en su concepción del mundo de usuario un requerimiento es tan fácil como eso pero muy probablemente para el mundo del desarrollador eso es totalmente difícil probablemente va a haber que cambiar algo dentro de lo que es la base de datos y eso me puede afectar enormemente el rendimiento de la misma entonces y los requerimientos deben de verse en conjunto con varios factores tal como lo menciona que el mundo del usuario el cual lo ve de una forma el del desarrollador que lo ve de otra forma en el mundo del sistema básicamente depende de la tecnología que vamos a utilizar verdad qué tan fácil puede ser programar por ejemplo en un lenguaje como java versos 1 como php pues esto tiene mucho que ver o como pues el exterior también lo ve estos requerimientos muchas veces se dice que los usuarios son ángeles o son demonios porque pues pueden poner las cosas tan fáciles o tan difíciles como ellos ven el mundo realmente entonces hay que considerar estas cuatro visiones al momento de obtener los requerimientos del software un documento de especificación de requerimientos podría ser este el utilizado por el propuesto más bien dicho por él y triple en su en la versión 830 creo que la última versión es la del 2005 a esta fecha probablemente haya algunas actualizaciones ya después de esta fecha que ha sido producido en esta clase entonces tenemos estas las secciones o sea de las cuales pues ese formato especifica cómo deben de darse los requerimientos o cómo deben de obtenerse esos requerimientos ahí tenemos un resumen general de lo que trata ese documento una introducción verdad y algo que es bastante claro que tengamos y dejemos dentro de ese documento son las definiciones es decir cómo vamos a entender ciertos conceptos por ejemplo un árbol en el calor de la ingeniería de software pues probablemente es una estructura de datos que voy a utilizar para implementar algo pero si estoy haciendo un software con un ingeniero agrónomo por ejemplo para él o un árbol es otra cosa entonces esas definiciones deben de estar totalmente claras al momento de desarrollar este documento una descripción general de lo que el sistema va a ser verdad quiénes son sus usuarios y cuáles son sus funciones qué restricciones tiene verdad si funciona en todos los sistemas operativos o no etcétera etcétera y luego pues los requisitos específicos o sea que se nos están dando interfaces de usuario funciones cuál es el rendimiento o sea que debe de obtenerse dentro de este sistema es decir el tiempo de respuesta no mayores a 3 segundos por ejemplo especial si está en la web a especificaciones de seguridad los apéndices y quienes son los creadores del sistema ya por último por si pues va a ver que en algún momento ir a consultarles sobre cómo se obtuvo tal requerimiento verdad este requerimiento básicamente nos lleva a algo que nosotros le llamamos el dominio de la aplicación el dominio de la aplicación no es más que pues verificar cuáles son las clases o los objetos que interactúan dentro de lo que es este sistema y es una forma de entender el sistema básicamente por así decirlo pues ustedes acá pueden ver ciertos conceptos qué tienen que ver con el funcionamiento de una universidad en el cual pues estamos modelando conceptos esto no tiene nada que ver absolutamente con la parte de programación con las clases que nosotros vamos a utilizar para programar básicamente en el modelo concepto de nosotros tenemos objetos del dominio o clases conceptuales tal como ya lo hemos dicho o sea no estamos definiendo en sí una clase que va a ser programada en un lenguaje específico modelo lo que nos va a hacer es a tener una perspectiva amplia de lo que yo estoy haciendo y como los objetos van a estar interactuando entre ellos para poder dar solución a lo que se nos está pidiendo este modelo tiene asociaciones entre esas clases es decir cómo se asocia o cómo trabaja una clase cómo está y por supuesto cómo vamos a tener que colocar el atributo muy probablemente algunas de estas clases nos van a servir para nuestra cualificación en una etapa posterior veamos este ejemplo un poco más ampliado de lo que habíamos estado hablando tenemos el concepto universidad con sus atributos y pues sus relaciones por ejemplo una universidad en este caso pues tiene departamentos o facultades igual tienen muchos estudiantes departamento pues implementa muchos cursos o dicta muchos cursos verdad y pues hay profesores que están asignados a cierto departamento o están contratados en general pues no hay una forma correcta de decir pues está empleado o está asignado a pues eso va a depender de la perspectiva del analista y pues el modelo es totalmente válido utilizando qué cualquier tipo de relación que nosotros querramos a tacharle a la relación que tenemos ahí normalmente estas categorías nos van a servir para identificar ese modelo conceptual por ejemplo nosotros podemos decir cuáles son esas organizaciones que intervienen dentro de nuestro mundo cuáles son los hechos que hay dentro de este mundo procesos reglas políticas catálogos etcétera ustedes pueden ver todas las categorías y algunos ejemplos de estas categorías por ejemplo en los hechos que nosotros podemos diagramar en este diagrama conceptual son las ventas los pagos reuniones colisiones aterrizajes tal como lo pueden ver ustedes ahí entonces esto es una forma de guiarnos para poder encontrar clases que nos ayuden a entender el modelo conceptual para el cual nosotros vamos a desarrollar el sistema normally repito el modelo constructor es un diagrama que ayuda a los desarrolladores ya los analistas a entender el modelo o más bien dicho el problema que se va a desarrollar de esta manera hemos podido observar cómo pues a través del proceso de ingeniería de requerimientos llegamos a un modelo conceptual donde pues tenemos clases y dentro de este proceso de ingeniería de requerimientos obtenemos básicamente las funciones del sistema gracias por haber visto la presentación bien [Música]
