Objetivo 1: Modelo de Negocios e Ingeniería de Requisitos
Una de las premisas clave de la Ingeniería es combinar ciertos elementos con determinadas características de una manera tal, que logren una acción en conjunto sin obtener errores. Para la Ingeniería del Software esta filosofía claramente se mantiene, y abarca diferentes áreas donde actualmente es imposible no hacer caso de ellas. Más allá de solo tratarse de sistemas informáticos, también contribuye a través del modelo de negocios para que éstas cumplan con un régimen que las haga funcionales.
De esta forma, un modelo de negocios consiste en expresar el conocimiento preciso de los procesos que lleva la organización y que pueden relacionarse con el sistema que se va a desarrollar. En estos modelos normalmente se requiere una visión general de la organización donde se va a desarrollar dicho modelo, desde sus más pequeños detalles en hardware, software, bases de datos, conexiones a internet, entre otros, para así brindar resultados más concisos y precisos. Esa visión general, además, debe incluir todo lo referente al objetivo del negocio, su estructura organizativa en cuanto a las dependencias y áreas que se involucran directamente con el sistema, procesos y usuarios responsables, volumen de la información del sistema actual, manejada a través de las transacciones o actualizaciones, entre otros.
Finalmente y ya con la cantidad necesaria ya recolectada, con la información obtenida, el equipo del proyecto informático de la empresa, consultores externos contratados por la empresa, elaborará el Modelo de Negocio que consiste en realizar un documento entregable que contiene: el Modelo de casos de usos del Negocio, el Modelo del Dominio y el Modelo de Objetos.
Para destacar brevemente, un modelo de casos de usos del Negocio se refiere a un modelo utilizando los diagramas de caso de usos que describen los procesos se ejecutan en las diferencias dependencias y que se relacionan con el sistema a desarrollar; un modelo de dominio se constituye por un diagrama de clases conceptuales y está compuesto por las "clases" que se han identificado en el análisis del negocio. Luego, en otra disciplina, y por tanto modelo, este diagrama conceptual será "traducido" propiamente a un diagrama de clases; finalmente, los modelos de objetos del dominio están asociados a cada uno de los casos de uso del negocio.
Para el modelado de negocios es crucial estar consciente de las actividades, componentes, fundamentos y requerimientos de la organización en la que se trabaja, ya que de allí es donde se realizarán las conclusiones pertinentes para llevar a cabo las actividades posteriores de la organización.
A la hora de realizar un modelo de negocios, se deben tener en cuenta factores importantes como la identificación y definición de los procesos de negocio según los objetivos de la organización, definición de un caso de uso del negocio para cada proceso del negocio; identificación de los roles implicados en los diferentes procesos del negocio; el modelo de flujo de tareas asociado a cada proceso de negocio mediante escenarios y diagramas de procesos, que muestren la interacción entre roles para conseguir el objetivo; y la especificación las informaciones y actividades incluidas en cada diagrama de actividad.
Como se pudo observar, para el modelo de negocio se necesita una descripción minuciosa y exhaustiva de los elementos y características que lo componen. Estos, a su vez, pueden verse como los requisitos de los cuales consta una organización para realizar un software optimo. Es por ello que es de importancia resaltar la ingeniería de requisitos a la hora de crear distintos software con vida útil.
Definimos a la ingeniería de requisitos como el proceso de desarrollar una especificación de Software. Dichas especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. Además, trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.
Ante esto, podemos dar por seguro que la ingeniería de requisitos es indispensable para gestionar las necesidades del proyecto en forma estructurada, mejorar la capacidad de predecir cronogramas de proyectos, así como sus resultados, disminuir los costos y retrasos del proyecto, además de mejorar la calidad del software y la comunicación entre equipos. La importancia de la ingeniería de requisitos recae en no sólo su minucioso detalle, sino en los beneficios que trae consigo.
Cabe destacar las características de requisitos que dividen esta ingeniería, ya que, al dividirlo en secciones distintas, es más sencillo llevar a cabo el trabajo. Estos tipos se dividen en: funcionales, no-funcionales, otros.
Un requisito funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requisito específica algo que el sistema entregado debe ser capaz de realizar.
Un requisito no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto
Observamos entonces, que al dividir los tipos de requisitos en diferentes partes se puede simplificar su elección de acuerdo a sus características, funciones, entre otros aspectos.
De igual manera, así como se dividen los requisitos a partir de su funcionalidad u otros aspectos, se hace también a partir de sus tipos. Estas se hacen a partir de distintas modalidades, de maneras textuales y graficas, y con el fin llegar a conclusiones y especificaciones más precisas. Las mismas se denominan como textual, notación grafica y lenguajes de representación como lo son el lenguaje unificado de modelado UML y notación de requerimientos del usuario URN.
Cuando nos referimos al tipo textual, hablamos de la especificación de requisitos que se ha realizado usando sobre todo especificaciones textuales en lenguaje natural. Estos requisitos expresados textualmente se enlazan formando un grafo de trazabilidad el cual se usa para gestionar los requisitos y su trazabilidad. En este enfoque, las especificaciones generadas en las otras actividades del desarrollo de software pueden también ser añadidas al grafo de trazabilidad representándolas como texto.
Por otra parte, cuando hablamos de notación gráfica, incluimos todas las notaciones que pueden demostrar el flujo de información entre requisitos, apoyándose en diversas imágenes. Estas notaciones permiten al usuario del sistema tener mayor comprensión del software lo que hace y como lo hace. La más utilizada actualmente es el Lenguaje Unificado de modelado (UML), lo cual nos lleva al último tipo, los lenguajes de representación.
Definimos como lenguaje de representación a un conjunto de etiquetas y atributos válidos y que ofrecen un significado visual para cada elemento del lenguaje, sino que ofrece un número de reglas sintácticas para poder crear documentos. En base a esto, se derivan dos importantes atributos del lenguaje de representación: el Lenguaje Unificado de Modelado (UML) y la Notación de Requerimiento de Usuario (URN).
El lenguaje Unificado de Modelado, conocido también por sus siglas como UML, Es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. Es usado para la comunicación. Es decir, un medio para capturar el conocimiento (semánticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propósito de la comunicación.
Como un lenguaje para modelamiento, se enfoca en la comprensión de un tema a través de la formulación de un modelo del tema (y su contexto respectivo). Cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y sistemas de información pasando por todos Los tipos de sistemas (software y no - software), dominios (negocios versus software) y los procesos de ciclo de vida.
Finalmente, tenemos la Notación de Requerimiento de Usuario (URN), la cual fue una iniciativa de la Internet Engineering Task Force IETF, la rama de desarrollo de ingeniería y protocolos de Internet, con la premisa de conseguir una forma universal de identificación de recursos, para que cada recurso fuera único y constante. Se trataba de un identificador paralelo al URL.
Una característica importante de este sistema es que trabaja junto con Uniform Resource Characteristics/Citacion (URC), un sistema para la descripción de metadatos. La sintaxis del URN, consta de 3 bloques separados por dos puntos: el identificador URN, el NID o nombre de la categoría en la que se incluye el documento (por ejemplo, inet para documentos de Internet) y el NSS o cadena específica que indica primero la ruta y a continuación el documento concreto.
URN es una notación pensada para la especificación, análisis y validación de los requisitos de usuario. URN combina dos vistas complementarias: una para definir los objetivos del sistema usando el Goal-oriented Requirement Language (GRL) y otra para definir los escenarios de uso con la notación Use Case Map (UCM).