UML

¿Qué es UML?

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para generar código en diversos lenguajes usando los diagramas UML. UML guarda una relación directa con el análisis y el diseño orientados a objetos.

UML y su función en el modelado y diseño orientados a objetos

Hay muchos paradigmas o modelos para la resolución de problemas en la informática, que es el estudio de algoritmos y datos. Hay cuatro categorías de modelos para la resolución de problemas: lenguajes imperativos, funcionales, declarativos y orientados a objetos (OOP). En los lenguajes orientados a objetos, los algoritmos se expresan definiendo 'objetos' y haciendo que los objetos interactúen entre sí. Esos objetos son cosas que deben ser manipuladas y existen en el mundo real. Pueden ser edificios, artefactos sobre un escritorio o seres humanos.
Los lenguajes orientados a objetos dominan el mundo de la programación porque modelan los objetos del mundo real. UML es una combinación de varias notaciones orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos.
UML usa las fortalezas de estos tres enfoques para presentar una metodología más uniforme que sea más sencilla de usar. UML representa buenas prácticas para la construcción y documentación de diferentes aspectos del modelado de sistemas de software y de negocios.

La historia y los orígenes de UML

"The Three Amigos" (los tres amigos) de la ingeniería de software, como se los conocía, habían desarrollado otras metodologías. Se asociaron para brindar claridad a los programadores creando nuevos estándares. La colaboración entre Grady, Booch y Rumbaugh fortaleció los tres métodos y mejoró el producto final.
Los esfuerzos de estos pensadores derivaron en la publicación de los documentos UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias organizaciones, incluidas Microsoft, Oracle e IBM, consideraron que UML era esencial para su propio desarrollo de negocios. Ellos, junto con muchas otras personas y compañías, establecieron los recursos necesarios para desarrollar un lenguaje de modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario para el Lenguaje Unificado de Modelado en 1999, y una actualización que incluye información sobre UML 2.0 en la segunda edición de 2005.

OMG: Tiene un significado diferente

Según su sitio web, el Object Management Group® (OMG®) es un consorcio internacional sin fines de lucro y de membresía abierta para estándares tecnológicos, fundado en 1989. Los estándares de OMG son promovidos por proveedores, usuarios finales, instituciones académicas y agencias gubernamentales. Los grupos de trabajo de OMG desarrollan estándares de integración empresarial para una amplia gama de tecnologías y una gama incluso más amplia de industrias. Los estándares de modelado de OMG, incluidos UML y Model Driven Architecture® (MDA®), permiten un eficaz diseño visual, ejecución y mantenimiento de software y otros procesos.
OMG supervisa la definición y el mantenimiento de las especificaciones de UML. Esta supervisión ofrece a los ingenieros y programadores la capacidad de usar un lenguaje para muchos propósitos durante todas las etapas del ciclo de vida del software en sistemas de cualquier tamaño.

La finalidad de UML según OMG

El OMG define los propósitos de UML de la siguiente manera:

• Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software las herramientas para el análisis, el diseño y la implementación de sistemas basados en software, así como para el modelado de procesos de negocios y similares.
• Hacer progresar el estado de la industria permitiendo la interoperabilidad de herramientas de modelado visual de objetos. No obstante, para habilitar un intercambio significativo de información de modelos entre herramientas, se requiere de un acuerdo con respecto a la semántica y notación.

UML cumple con los siguientes requerimientos:

• Establecer una definición formal de un metamodelo común basado en el estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del UML. La sintaxis abstracta define el conjunto de conceptos de modelado UML, sus atributos y sus relaciones, así como las reglas de combinación de estos conceptos para construir modelos UML parciales o completos.
• Brindar una explicación detallada de la semántica de cada concepto de modelado UML. La semántica define, de manera independiente a la tecnología, cómo los conceptos UML se habrán de desarrollar por las computadoras.
• Especificar los elementos de notación de lectura humana para representar los conceptos individuales de modelado UML, así como las reglas para combinarlos en una variedad de diferentes tipos de diagramas que corresponden a diferentes aspectos de los sistemas modelados.
• Definir formas que permitan hacer que las herramientas UML cumplan con esta especificación. Esto se apoya (en una especificación independiente) con una especificación basada en XML de formatos de intercambio de modelos correspondientes (XMI) que deben ser concretados por herramientas compatibles.

UML y el modelado de datos

El UML es popular entre programadores, pero no suele ser usado por desarrolladores de bases de datos. Una razón es sencillamente que los creadores de UML no se enfocaron en las bases de datos. A pesar de ello, el UML es efectivo para el modelado de alto nivel de datos conceptuales y se puede usar en diferentes tipos de diagramas UML. Puedes encontrar información sobre la multidimensionalidad de un modelo de clases orientado a objetos en una base de datos relacional en este artículo sobre Modelado de bases de datos en UML.

Actualizaciones en UML 2.0

El UML se perfecciona continuamente. UML 2.0 extiende las especificaciones de UML para cubrir más aspectos de desarrollo, incluido Agile. La meta era reestructurar y perfeccionar UML de forma que la facilidad de uso, la implementación y la adaptación se simplificaran. Estas son algunas de las actualizaciones de los diagramas UML:

• Mayor integración entre modelos estructurales y de comportamiento.
• Capacidad de definir jerarquía y desglosar un sistema de software en componentes y subcomponentes.
• UML 2.0 eleva el número de diagramas de 9 a 13.

Glosario de términos de UML

Familiarízate con el vocabulario de UML, con esta lista extraída del documento UML 2.4.1, cuya finalidad es ayudar a quienes no son miembros de OMG a entender los términos comúnmente usados.

• Compatibilidad con sintaxis abstracta Los usuarios pueden mover modelos a través de diferentes herramientas, incluso si usan diferentes notaciones.
• Metamodelo de almacén común (CWM) Interfaces estándares que se usan para permitir el intercambio de metadatos de almacén e inteligencia de negocios entre herramientas de almacén, plataformas de almacén y repositorios de metadatos de almacén en entornos heterogéneos distribuidos.
• Compatibilidad con sintaxis concreta Los usuarios pueden continuar usando una notación con la que estén familiarizados a través de diferentes herramientas.
• Núcleo En el contexto de UML, el núcleo comúnmente se refiere al "paquete central", que es un metamodelo completo particularmente diseñado para una alta reutilización.
• Unidad de lenguaje Consiste en una colección de conceptos de modelado estrechamente vinculados que proporciona a los usuarios la capacidad de representar aspectos del sistema en estudio según un paradigma o formalismo en particular.
• Nivel 0 (L0) Nivel de cumplimiento inferior para la infraestructura UML - una sola unidad de lenguaje que hace posible el modelado de tipos de estructuras basadas en clases que se encuentran en los lenguajes más populares de programación orientados a objetos.
• Meta Object Facility (MOF) Una especificación de modelado de OMG que brinda la base para las definiciones de metamodelos en la familia de lenguajes MDA de OMG.
• Metamodelo Define el lenguaje y los procesos a partir de los cuales formar un modelo.
• Construcciones de metamodelos (LM) Segundo nivel de cumplimiento en la infraestructura UML - una unidad adicional de lenguaje para estructuras más avanzadas basadas en clases, usadas para construir metamodelos (por medio de CMOF), tales como el UML mismo. UML solo tiene dos niveles de cumplimiento.
• Arquitectura dirigida por modelos (MDA) Un enfoque y un plan para lograr un conjunto coherente de especificaciones de tecnología dirigida por modelos.
• Lenguaje de restricciones para objetos (OCL) Un lenguaje declarativo para describir reglas que se aplican al Lenguaje Unificado de Modelado. OCL complementa a UML proporcionando términos y símbolos de diagramas de flujo que son más precisos que el lenguaje natural, pero menos difíciles de dominar que las matemáticas.
• Object Management Group (OMG) Es un consorcio sin fines de lucro de especificaciones para la industria de la computación, cuyos miembros definen y mantienen la especificación UML.
• UML 1 Primera versión del Lenguaje Unificado de Modelado.
• Lenguaje Unificado de Modelado (UML) Un lenguaje visual para especificar, construir y documentar los artefactos de los sistemas.
• XMI Una especificación basada en XML de formatos de intercambio de modelos correspondientes.

Ver el documento MOF completo
Descargar el documento de Infraestructura UML 2.4.1completo.

Conceptos de modelado especificados por UML

El desarrollo de sistemas se centra en tres modelos generales de sistemas diferentes:

• Funcionales: Se trata de diagramas de casos de uso que describen la funcionalidad del sistema desde el punto de vista del usuario.
• De objetos: Se trata de diagramas de clases que describen la estructura del sistema en términos de objetos, atributos, asociaciones y operaciones.
• Dinámicos: Los diagramas de interacción, los diagramas de máquina de estados y los diagramas de actividades se usan para describir el comportamiento interno del sistema.

Estos modelos de sistemas se visualizan a través de dos tipos diferentes de diagramas: estructurales y de comportamiento.

Conceptos orientados a objetos en UML

Los objetos en UML son entidades del mundo real que existen a nuestro alrededor. En el desarrollo de software, los objetos se pueden usar para describir, o modelar, el sistema que se está creando en términos que sean pertinentes para el dominio. Los objetos también permiten la descomposición de sistemas complejos en componentes comprensibles que permiten que se construya una pieza a la vez.
Estos son algunos conceptos fundamentales de un mundo orientado a objetos:

• Objetos Representan una entidad y el componente básico.
• Clase Plano de un objeto.
• Abstracción Comportamiento de una entidad del mundo real.
• Encapsulación Mecanismo para enlazar los datos y ocultarlos del mundo exterior.
• Herencia Mecanismo para crear nuevas clases a partir de una existente.
• Polimorfismo Define el mecanismo para salidas en diferentes formas.

Tipos de diagramas UML

UML usa elementos y los asocia de diferentes formas para formar diagramas que representan aspectos estáticos o estructurales de un sistema, y diagramas de comportamiento, que captan los aspectos dinámicos de un sistema.
Diagramas UML estructurales

• Diagrama de clases El diagrama UML más comúnmente usado, y la base principal de toda solución orientada a objetos. Las clases dentro de un sistema, atributos y operaciones, y la relación entre cada clase. Las clases se agrupan para crear diagramas de clases al crear diagramas de sistemas grandes.
• Diagrama de componentes Muestra la relación estructural de los elementos del sistema de software, muy frecuentemente empleados al trabajar con sistemas complejos con componentes múltiples. Los componentes se comunican por medio de interfaces.
• Diagrama de estructura compuesta Los diagramas de estructura compuesta se usan para mostrar la estructura interna de una clase.
• Diagrama de implementación Ilustra el hardware del sistema y su software. Útil cuando se implementa una solución de software en múltiples máquinas con configuraciones únicas.
• Diagrama de objetos Muestra la relación entre objetos por medio de ejemplos del mundo real e ilustra cómo se verá un sistema en un momento dado. Dado que los datos están disponibles dentro de los objetos, estos pueden usarse para clarificar relaciones entre objetos.
• Diagrama de paquetes Hay dos tipos especiales de dependencias que se definen entre paquetes: la importación de paquetes y la fusión de paquetes. Los paquetes pueden representar los diferentes niveles de un sistema para revelar la arquitectura. Se pueden marcar las dependencias de paquetes para mostrar el mecanismo de comunicación entre niveles.

Diagramas UML de comportamiento

• Diagramas de actividades Flujos de trabajo de negocios u operativos representados gráficamente para mostrar la actividad de alguna parte o componente del sistema. Los diagramas de actividades se usan como una alternativa a los diagramas de máquina de estados.
• Diagrama de comunicación Similar a los diagramas de secuencia, pero el enfoque está en los mensajes que se pasan entre objetos. La misma información se puede representar usando un diagrama de secuencia y objetos diferentes.
• Diagrama de panorama de interacciones Hay siete tipos de diagramas de interacciones. Este diagrama muestra la secuencia en la cual actúan.
• Diagrama de secuencia Muestra cómo los objetos interactúan entre sí y el orden de la ocurrencia. Representan interacciones para un escenario concreto.
• Diagrama de máquina de estados Similar a los diagramas de actividades, describen el comportamiento de objetos que se comportan de diversas formas en su estado actual.
• Diagrama de temporización Al igual que en los diagramas de secuencia, se representa el comportamiento de los objetos en un período de tiempo dado. Si hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las interacciones de los objetos se muestran durante ese período de tiempo particular.
• Diagrama de caso de uso Representa una funcionalidad particular de un sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus controladores (actores) internos/externos.

Cómo crear un diagrama UML: Tutoriales y ejemplos

Para ilustrar cómo crear diferentes tipos de diagramas UML, prueba uno o todos estos tutoriales para guiarte a través del proceso de trazar diagramas tanto estructurales como de comportamiento.
Ejemplos de tutoriales de diagramas estructurales
DIAGRAMAS DE CLASES
Los diagramas de clases representan las estructuras estáticas de un sistema, incluidas sus clases, atributos, operaciones y objetos. Un diagrama de clases puede mostrar datos computacionales u organizacionales en la forma de clases de implementación y clases lógicas, respectivamente. Puede haber superposición entre estos dos grupos.

1. Las clases se representan con una forma rectangular dividida en tercios. La sección superior muestra el nombre de la clase, mientras que la sección central contiene los atributos de la clase. La sección inferior muestra las operaciones de la clase (también conocidas como métodos).
2. Agrega formas de clases a tu diagrama de clases para modelar la relación entre esos objetos. Además, podría ser necesario que agregues subclases.
3. Usa líneas para representar asociación, traspaso, multiplicidad y otras relaciones entre clases y subclases. Tu estilo de notación preferido informará la notación de estas líneas.

DIAGRAMAS DE COMPONENTES
Los diagramas de componentes muestran cómo se combinan los componentes para formar componentes más grandes o sistemas de software. Estos diagramas están diseñados para modelar las dependencias de cada componente en el sistema. Un componente es algo necesario para ejecutar una función de estereotipo. Un estereotipo de componente puede constar de ejecutables, documentos, tablas de bases de datos, archivos o archivos de bibliotecas.

1. Representa un componente con una forma rectangular. Debe tener dos rectángulos pequeños en un lado o mostrar un icono con esa forma.
2. Agrega líneas entre formas de componentes para representar las relaciones pertinentes.

DIAGRAMAS DE IMPLEMENTACIÓN
Un diagrama de implementación modela la implementación física y la estructura de los componentes de hardware. Los diagramas de implementación muestran dónde y cómo operarán los componentes de un sistema en conjunto con los demás.

1. Al trazar un diagrama de implementación, usa la misma notación que usas para un diagrama de componentes.
2. Usa un cubo 3D para modelar un nodo (lo cual representa una máquina física o máquina virtual).
3. Etiqueta el nodo con el mismo estilo que se usa para los diagramas de secuencia. Agrega otros nodos según sea necesario, luego conéctalos con líneas.

Ejemplos de tutoriales de diagramas de comportamiento
Diagrama de actividades
Los diagramas de actividades muestran el flujo de control de procedimiento entre objetos de clases, junto con procesos organizacionales, como los flujos de trabajo de negocios. Estos diagramas se integran con formas especializadas que luego se conectan con flechas. La notación establecida para los diagramas de actividades es similar a la de los diagramas de estados.

1. Empieza tu diagrama de actividades con un círculo negro.
2. Conecta el círculo a la primera actividad, la cual se modela con un rectángulo redondeado.
3. Ahora, conecta cada actividad a otras actividades con líneas que muestren el flujo paso a paso de todo el proceso.
4. También puedes probar usar carriles para representar los objetos que realizan cada actividad.

Diagrama de caso de uso
Un caso de uso es una lista de pasos que definen la interacción entre un actor (un humano que interactúa con el sistema o un sistema externo) y el sistema propiamente dicho. Los diagramas de casos de uso representan las especificaciones de un caso de uso y modelan las unidades funcionales de un sistema. Estos diagramas ayudan a los equipos de desarrollo a comprender los requisitos de su sistema, incluida la función de la interacción humana en el mismo y las diferencias entre diversos casos de uso. Un diagrama de caso de uso podría mostrar todos los casos de uso del sistema o solo un grupo de casos de uso con una funcionalidad similar.

1. Para iniciar un diagrama de casos de uso, agrega una forma ovalada en el centro del dibujo.
2. Escribe el nombre del caso de uso dentro del óvalo.
3. Representa a los actores con una figura humana cerca del diagrama, luego usa líneas para modelar las relaciones entre los actores y los casos de uso.

Diagrama de secuencia
Los diagramas de secuencia, también conocidos como diagramas de eventos o escenarios de eventos, ilustran cómo los procesos interactúan entre sí mostrando llamadas entre diferentes objetos en una secuencia. Estos diagramas tienen dos dimensiones: vertical y horizontal. Las líneas verticales muestran la secuencia de mensajes y llamadas en orden cronológico y los elementos horizontales muestran instancias de objetos en las que se transmiten los mensajes.

1. Para crear un diagrama de secuencia, escribe el nombre de la instancia de clase y el nombre de la clase en un cuadro rectangular.
2. Dibuja líneas entre las instancias de clases para representar al emisor y receptor de los mensajes.
3. Usa puntas de flecha oscuras para simbolizar mensajes sincrónicos, puntas de flecha abiertas para mensajes asincrónicos y líneas discontinuas para mensajes de respuesta.

Lucidchart facilita dibujar diagramas UML

Puedes empezar a crear diagramas UML ahora mismo con Lucidchart. Con nosotros es más sencillo, eficaz e incluso divertido.

• Sencillo de usar Facilidad de uso. Si estás creando un diagrama UML, sabes claramente lo que estás haciendo, pero queremos que realices el trabajo de la forma más sencilla posible. Ahorrarás tiempo con la interfaz refinada y el editor inteligente de arrastrar y soltar de Lucidchart.
• Amplia biblioteca de formas Dibuja diagramas de estados, diagramas de actividades, diagramas de casos de uso y mucho más. Con una amplia biblioteca de formas y conectores, encontrarás todo lo que necesites.
• Integración total Lucidchart está totalmente integrado con G Suite. Una vez que hayas empezado con Lucidchart, podrás encontrarnos directamente en tu conjunto de aplicaciones de productividad de Google junto co

INGENIERIA DE REQUISITOS

INGENIERÍA DE REQUERIMIENTOS.


2. INGENIERÍA DE REQUISITOS

 La ingeniería de requisitos, según Pressman [Pressman 05], es un conjunto de procesos, tareas y técnicas que permiten la definición y gestión de los requisitos de un producto de un modo sistemático. En definitiva, facilita los mecanismos adecuados para comprender las necesidades del cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. La ingeniería de requisitos permite la gestión adecuada de los requisitos de un proyecto de desarrollo software. Además, mejora la capacidad para realizar planificaciones de los procesos de proyectos de desarrollo software puesto que el conocer qué se tiene que desarrollar permite una efectiva proyección de las actividades, recursos, costos, tiempos, etc. del proyecto. Según Sommerville [Sommerville 05], se puede considerar como el proceso de comunicación entre los clientes, los usuarios del software y los desarrolladores del mismo. Llevar a cabo de manera adecuada el proceso de ingeniería de requisitos disminuye la probabilidad de fracaso de un proyecto. Esto es porque los requisitos bien definidos permiten conocer de un modo conciso que debe ser capaz de realizar el software a desarrollar y hace orientar las actividades, recursos y esfuerzos de manera eficiente permitiendo la disminución de costos y retrasos. Todo ello provoca una mejora en la calidad del software puesto que los requisitos bien especificados podrán probarse de manera efectiva y, por tanto, cumplirse.


2.1. Fases en ingeniería de requisitos

 La definición de las necesidades del sistema juega un papel fundamental en el proceso de desarrollo del software (SPD). Esta definición es un proceso complejo puesto que en él hay que identificar los requisitos que el Patrón de clasificación de tipos de requisitos Página 4 de 107 sistema debe cumplir para satisfacer las necesidades. Para realizar este proceso, no existe una única técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado. La delimitación de ingeniería de requisitos no es del todo clara puesto que incluso, hay autores que, dentro de la ingeniería de requisitos, generan modelos estáticos de clases que son entendidos por otros autores como tareas de una fase posterior. Dentro de las posibles estructuras que se pueden definir en la fase de ingeniería de requisitos, la propuesta con mayor seguimiento es la establecida por Lowe y Hall [Lowe y Hall 99]. En ella, el proceso de tratamiento de requisitos está compuesto por tres actividades: - Captura de requisitos. - Definición de requisitos. - Validación de requisitos. Se puede representar este proceso de ingeniería de requisitos como un diagrama de actividades en UML, tal como se muestra en la ilustración 1. Es posible plantear el estudio de viabilidad y la gestión de requisitos en el proceso de tratamiento de requisitos. Ilustración 1: Proceso Ingeniería Requisitos Patrón de clasificación de tipos de requisitos Página 5 de 107 El estudio de viabilidad permite definir de modo global la funcionalidad y ver si es factible su ejecución dentro del aspecto económico y del tiempo establecido, elaborando para ello un informe de viabilidad. La gestión de requisitos permite las posibles actualizaciones y cambios que pueden sufrir los requisitos, dando lugar a versiones del documento de requisitos. Esta actividad se desarrolla a lo largo de todo el proceso de desarrollo software.

 2.1.1. Captura de requisitos

La captura de requisitos es la actividad en la que un grupo especializado extrae, de cualquier fuente de información disponible (documentos, aplicaciones existentes, entrevistas, etc.), las necesidades de cubrir dicho sistema. El proceso de captura de requisitos puede resultar complejo, debido a esto existen un conjunto de técnicas que permiten hacer este proceso de una forma más eficiente y precisa, obteniéndose necesidades y modelos del sistema. A continuación se enumeran un grupo de técnicas que son utilizadas para esta actividad: - Entrevistas. Permiten tomar conocimiento del problema y comprender los objetivos de la solución buscada. - Desarrollo de conjunto de aplicaciones. Es una práctica de grupo donde participan usuarios, analistas, administradores del sistema, y clientes y en la que se concretan las necesidades del sistema. - Tormenta de ideas. Consiste en la mera acumulación de ideas sin evaluar las mismas. Ofrece una visión general de las necesidades del sistema pero sin ofrecer detalles concretos. - Mapa conceptual. Grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Estos grafos sirven para aclarar los conceptos relacionados con el sistema a desarrollar, ofreciendo una visión general de las necesidades del sistema. Patrón de clasificación de tipos de requisitos Página 6 de 107 - Casos de uso. Muestran el contorno (actores) y el alcance del sistema (requisitos expresados como casos de uso). Un caso de uso describe la secuencia de interacciones que se producen entre el sistema y los actores del mismo para realizar una determinada función. La ventaja principal de los casos de uso es que resultan muy fáciles de entender para el cliente, sin embargo pueden carecer de a precisión necesaria, es por ello que pueden acompañarse de una información textual. - Cuestionarios. Recoge información del sistema de forma independiente de la entrevista.

 2.1.2. Definición de requisitos

 Para la definición de los requisitos son usados lenguajes naturales que, a pesar de poder ser ambiguos y/o extensos, su coste reducido hace que sean la alternativa común a los lenguajes formales. Es necesario elaborar el documento de requisitos, en el cual, se definen los objetivos y necesidades del sistema. Existe un conjunto de técnicas propuestas para esta actividad: - Lenguajes naturales y formales. Los lenguajes naturales es una técnica muy ambigua en contraposición a los lenguajes formales. - Ontologías. Donde se definen los conceptos que intervienen en la definición del sistema así como las relaciones que existen entre ellos. - Patrones. Define los requisitos mediante el lenguaje natural pero de una manera estructurada. Una plantilla es una tabla con una serie de campos y una estructura predefinida. Es necesario clasificar el conjunto de requisitos, pudiendo generarse un catálogo distinto dependiendo del estándar utilizado. Patrón de clasificación de tipos de requisitos Página 7 de 107 2.1.3. Validación de requisitos Por último, se procede a la validación de requisitos, llevándose a cabo la valoración de los mismos, comprobando la veracidad, consistencia y completitud de requisitos. Las técnicas existentes para desarrollar esta actividad son: - Revisiones de verificabilidad. Consiste en la lectura y corrección de la documentación o modelado de la definición de requisitos. - Auditorías. Consiste en un chequeo de los resultados. - Matrices de trazabilidad. Consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo que objetivos cubre cada requisito para detectar inconsistencias u objetivos no cubiertos. - Prototipos. Permite que el usuario se haga una idea del sistema. Los requisitos han de ser gestionados mediante el llamado plan de gestión de requisitos que establece las medidas, el método, soporte y técnicas para almacenar los requisitos, gestionar el cambio de éstos (debido a que pueden ser volátiles) y gestionar su trazabilidad.

 2.2. Evolución y negociación de los requisitos

 Desde el principio, se pretende especificar los requisitos de forma detallada pero es casi imposible conocer al principio del proyecto todos los detalles del futuro software. En la práctica, los requisitos son cambiantes dentro del proceso iterativo y evolutivo del software. Pueden existir muchos problemas en los proyectos software por la volatibilidad de los requisitos, muchos clientes desean que se añadan o modifiquen nuevos requisitos por el mismo precio y es tarea del ingeniero negociar esas nuevas funcionalidades no presentadas en el pliego inicial. Es por esto que para llevar con éxito un proyecto, es necesario el contacto continuado entre el cliente y el ingeniero software para conocer las Patrón de clasificación de tipos de requisitos Página 8 de 107 dificultades y necesidades de ambas partes y así buscar una solución de manera conjunta.

2.3. Necesidad del establecimiento y gestión de requisitos

La necesidad de modelar los requisitos dado un sistema tiene una importancia vital puesto que sin éstos el equipo no sabes cuales son las metas a lograr, ni puede inspeccionar y probar su trabajo de modo adecuado, ni puede controlar su productividad, ni puede obtener datos que se adecuen a las pruebas, ni pueden predecir el tamaño y esfuerzo del proyecto. En definitiva, no hay ingeniería completa sin requisitos escritos. Muchos proyectos iniciados no llegan a finalizarse o aquellos que son terminados, incurren en mayores costes y tiempos o no incluyen la totalidad de los requisitos iniciales. Una de las causas de este problema es la deficiente captura y gestión de los requisitos. Otro punto importante de la ingeniería de requisitos es la adecuada gestión de los requisitos que se puede considerar como el factor más relevante para el éxito o el fracaso de un proyecto. Esto es motivado por lo cambiante que son los requisitos. El plan de gestión de requisitos define las medidas, métodos, soportes y técnicas para almacenar los requisitos, gestionar el posible cambio de éstos así como su trazabilidad. La gestión de requisitos no es una tarea sencilla, Chiristel y Kang [Christel y Kang 92], plantean una serie de inconvenientes:  Problemas de alcance. Esto es debido a que es complejo especificar los límites que abarcan los requisitos.  Problemas de comprensión. Esto es debido a que los clientes y usuarios no suelen estar completamente seguros de lo que quieren.  Problemas de volatibilidad. Esto es debido a que los requisitos pueden cambiar con el tiempo puesto que durante el proceso mismo del desarrollo los requisitos evolucionan.

CAPTURA PROYECT

METODOLOGIA

Enfoques de desarrollo de software

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:¹​

• Modelo en cascada: Framework lineal.
• Prototipado: Framework iterativo.
• Incremental: Combinación de framework lineal e iterativo.
• Espiral: Combinación de framework lineal e iterativo.
• RAD: Rapid Application Development, framework iterativo.

Modelo en cascada

Es un proceso secuencial, fácil de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implantación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W.²​ en 1970, aunque Royce no utiliza el término "cascada" de este artículo.

Los principios básicos del modelo de cascada son los siguientes:¹​

• El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.
• Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.
• Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff hechas por el usuario y la gestión del área TI al final de la mayoría de las fases y antes de comenzar la próxima fase.

Prototipado

El prototipado permite desarrollar modelos de aplicaciones de software que permiten ver la funcionalidad básica de la misma, sin necesariamente incluir toda la lógica o características del modelo terminado. El prototipado permite al cliente evaluar en forma temprana el producto, e interactuar con los diseñadores y desarrolladores para saber si se está cumpliendo con las expectativas y las funcionalidades acordadas. Los Prototipos no poseen la funcionalidad total del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, y maneja un alto grado de participación del usuario.

Incremental

Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.

Los principios básicos son:

• Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequeña parte de los sistemas, antes de proceder a la próxima incremental.
• Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema.
• El concepto inicial de software, análisis de las necesidades, y el diseño de la arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalación del prototipo final.

Espiral

Los principios básicos son:

• La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo, así como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideración de la continuación del proyecto durante todo el ciclo de vida.
• Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteración; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteración, y (4) plan de la próxima iteración.³​
• Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia, y termina con la revisión y examinación.³​

Rapid Application Development (RAD)

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.

Principios básicos:

• Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión.
• Intenta reducir el riesgos inherente del proyecto partiéndolo en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.
• Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promueve la participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos.
• Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia es de menor importancia.
• Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite.
• En general incluye Joint application development (JAD), donde los usuarios están intensamente participando en el diseño del sistema, ya sea a través de la creación de consenso estructurado en talleres, o por vía electrónica.
• La participación activa de los usuarios es imprescindible.
• Iterativamente realiza la producción de software, en lugar de enfocarse en un prototipo.
• Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.

Otros enfoques de desarrollo de software

• Metodologías de desarrollo Orientado a objetos, Diseño orientado a objetos (OOD) de Grady Booch, también conocido como Análisis y Diseño Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transición, la interacción, módulo, y el proceso.
• Top-down programming, evolucionado en la década de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado.
• Proceso Unificado, es una metodología de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecución de una o más iteraciones de desarrollo de software: creación, elaboración, construcción, y las directrices. Hay una serie de herramientas y productos diseñados para facilitar la aplicación. Una de las versiones más populares es la de Rational Unified Process.

FASES

Las cinco etapas de ingeniería del software

¿ Es necesaria la ingeniería del software ?

Desafortunadamente he visto muchos proyectos de software fallar estrepitosamente por no seguir ninguna metodología. Con muy buenas intenciones se empieza rápidamente a construir con sólo una idea aproximada de lo que se quiere desarrollar y con un plan aún más impreciso de cómo hacerlo. Aplicar las etapas de la ingeniería del software acostumbra ser una buena idea que te permite estructurar el producto y enfocar su construcción con éxito.

La ingeniería del software es el proceso formal de desarrollo de software en el que las necesidades del usuario se traducen en requerimientos, estos se transforman en diseño que se implementa en código que se prueba, documenta y se certifica para su uso operativo. Según la definición del IEEE la ingeniería del software se define como “(1) la aplicación de un método sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, esto es, la aplicación de la ingeniería al software” y “(2) el estudio de los métodos de (1)”

El proceso requiere una metodología con 5 etapas:

1.  Análisis de requerimientos: Se extraen los requisitos del producto de software. En esta etapa la habilidad y experiencia en la ingeniería del software es crítica para reconocer requisitos incompletos, ambiguos o contradictorios. Usualmente el cliente/usuario tiene una visión incompleta/inexacta de lo que necesita y es necesario ayudarle para obtener la visión completa de los requerimientos.  El contenido de comunicación en esta etapa es muy intenso ya que el objetivo es eliminar la ambigüedad en la medida de lo posible.
2. Especificación: Es la tarea de describir detalladamente el software a ser escrito, de una forma rigurosa. Se describe el comportamiento esperado del software y su interacción con los usuarios y/o otros sistemas.
3. Diseño y arquitectura: Determinar como funcionará de forma general sin entrar en detalles incorporando consideraciones de la implementación tecnológica, como el hardware, la red, etc.  Consiste en el diseño de los componentes del sistema que dan respuesta a las funcionalidades descritas en la segunda etapa también conocidas como las entidades de negocio. Generalmente se realiza en base a diagramas que permitan describir las interacciones entre las entidades y su secuenciado.
4. Programación: Se traduce el diseño a código. Es la parte más obvia del trabajo de ingeniería de software y la primera en que se obtienen resultados “tangibles”. No necesariamente es la etapa más larga ni la más compleja aunque una especificación o diseño incompletos/ambiguos pueden exigir que, tareas propias de las etapas anteriores se tengan que realizarse en esta.
5. Prueba: Consiste en comprobar que el software responda/realice correctamente las tareas indicadas en la especificación. Es una buena praxis realizar pruebas a distintos niveles (por ejemplo primero a nivel unitario y después de forma integrada de cada componente) y por equipos diferenciados del de desarrollo (pruebas cruzadas entre los programadores o realizadas por un área de test independiente).
6. Documentación: Realización del manual de usuario, y posiblemente un manual técnico con el propósito de mantenimiento futuro y ampliaciones al sistema. Las tareas de esta etapa se inician ya en el primera fase pero sólo finalizan una vez terminadas las pruebas.
7. Mantenimiento: En esta etapa se realizan un mantenimiento correctivo (resolver errores) y un mantenimiento evolutivo (mejorar la funcionalidades y/o dar respuesta a nuevos requisitos).

Los más atentos habéis contado 7 en lugar de 5. No es un error. La sexta etapa, documentar, se tiene que llevar a cabo absolutamente en todas y aunque no es una etapa propiamente dicha pero es tan importante que debe ser mencionada explícitamente.

Por último la etapa del mantenimiento, sobretodo para ampliar el sistema con nuevas funciones, debe tener las “sub-etapas” 1 a 5 si se quiere abordar con garantías.

CONCEPTOS DE INGENIERIA DE SOFTWARE

La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (software).


Esta disciplina trasciende la actividad de programación, que es el pilar fundamental a la hora de crear una aplicación. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.
La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.


Cabe destacar que el proceso de desarrollo de software implica lo que se conoce como ciclo de vida del software, que está formado por cuatro etapas: concepción, elaboración, construcción y transición.
La concepción fija el alcance del proyecto y desarrolla el modelo de negocio; la elaboración define el plan del proyecto, detalla las características y fundamenta la arquitectura; la construcción es el desarrollo del producto; y la transición es la transferencia del producto terminado a los usuarios.
Una vez que se completa este ciclo, entra en juego el mantenimiento del software. Se trata de una fase de esta ingeniería donde se solucionan los errores descubiertos (muchas veces advertidos por los propios usuarios) y se incorporan actualizaciones para hacer frente a los nuevos requisitos. El proceso de mantenimiento incorpora además nuevos desarrollos, para permitir que el software pueda cumplir con una mayor cantidad de tareas.
Un campo directamente relacionado con la ingeniería de software es la arquitectura de sistemas, que consiste en determinar y esquematizar la estructura general del proyecto, diagramando su esqueleto con un grado relativamente alto de especificidad y señalando los distintos componentes que serán necesarios para llevar a cabo el desarrollo, tales como aplicaciones complementarias y bases de datos. Se trata de un punto fundamental del proceso, y es muchas veces la clave del éxito de un producto informático.


Los avances tecnológicos y su repercusión en la vida social han afectado inevitablemente el proceso de desarrollo de software por diversos motivos, como ser el acceso indiscriminado de los usuarios a cierta información que hasta hace un par de décadas desconocía por completo y que no pueden comprender, dado que no poseen el grado de conocimiento técnico necesario. Un consumidor bien informado es un consumidor al que no se puede timar, ya que sabe lo que necesita y tiene la capacidad de analizar las diferentes ofertas del mercado, comparando las propuestas y prestaciones de los productos; sin embargo, un consumidor mal informado es como un niño caprichoso que llora, grita y patalea sin parar.