Unidad 1

La Ingeniería de Sistemas se centra en obtener productos o servicios para transformar o controlar la información (la
Ingeniería de SW es parte de la Ing Sist). Para poder describir las características y comportamientos de los sistemas. Se
utiliza la Teoría General de Sistemas; ésta es una forma sistemática y científica de aproximación y representación de la
realidad. En esta se define el concepto básico de ambiente: área de sucesos y condiciones que influyen sobre el
comportamiento de un sistema. Un sistema absorbe selectivamente aspectos del ambiente. La desventaja de esta
relación es que se especializa el sistema respecto a su ambiente, por entre disminuye su capacidad de reacción frente a
los cambios externos.

Jerarquía en la Ingeniería de sistemas: Sin importar cuál sea el producto específico que se está tratando de hacer, la
ingeniería de sistemas sigue ciertos procesos. Se empieza con una visión global, es decir, se examina el dominio entero
del negocio o producto del sistema para establecer el contexto apropiado.

Modelo de Negocio: Es la parte alta de la jerarquía, estudia un contexto muy amplio y dirige la parte baja, ósea las
actividades técnicas detalladas. Dentro de este dominio específico, se analiza qué elementos necesitará el sistema (HW,
SW.

Modelado del sistema: define y representa el comportamiento de los procesos (actividades clave) y en qué se basa el
comportamiento (propuesta, recursos, costos, canales). Define explícitamente las entradas de información al modelo
(relación con clientes?, propuesta?). Representa todas las uniones (socios, clientes, relación con clientes) que permiten
al ingeniero entender mejor la visión.

Un ejemplo de cómo mostrar esto es mediante un modelo canvas. Es un concepto que permite visualizar en un sólo
gráfico un modelo de negocio según 9 campos preestablecidos, mostrando las interconexiones entre sus diferentes
elementos que intervienen en el mismo.

Requerimiento: o atributo de calidad, acción de requerir, vista por parte del cliente. Un requerimiento explica la
operación general de un sistema, no sus comportamientos específicos.

Requisito: característica que debe incluirse en un nuevo sistema.

• Funcionales: definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el
sistema realiza sobre las entradas para producir salidas.
• No Funcionales: tienen que ver con características que de una u otra forma puedan limitar el sistema, como por
ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. Complementan a los RF,
enfocándose en el diseño o la implementación.

Ingeniería de requisitos: es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras.

Las requerimientos de software pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del
sistema. El espectro amplio de tareas y técnicas que llevan a entender los requerimientos se denomina ingeniería de
requerimientos.

La ingeniería de requisitos proporciona el mecanismo para entender lo que desea el cliente, analizar las necesidades,
evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la
especificación y administrar los requerimientos a medida que se transforman en un sistema funcional.

Concepción. Se identifica cómo inicia el proyecto de software. En general, la mayor parte de los proyectos comienzan
cuando se identifica una necesidad del negocio o se descubre un nuevo mercado o servicio potencial. Los participantes
de la comunidad del negocio definen una idea, analizan el mercado, hacen un análisis de factibilidad e identifica el
alcance del proyecto. Toda esta información está sujeta a cambio, pero es suficiente para desencadenar análisis con la
organización de ingeniería de software. En esta etapa se establece el entendimiento básico del problema, las personas
que quieren una solución y la naturaleza de la solución que se desea.

Indagación. Preguntar al cliente, a los usuarios y a otras personas cuáles son los objetivos para el sistema o producto,
qué es lo que quiere lograrse, cómo se ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va
a usarse el sistema o producto. Problemas que se encuentran cuando ocurre la indagación:

• Problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios que han sido
aportados por los clientes/usuarios pueden confundir más que clarificar los objetivos del sistema.
• Problemas de entendimiento. Los clientes o usuarios no están completamente seguros de lo que se necesita, no
entienden el dominio del problema, tienen problemas para comunicar las necesidades al ingeniero de sistemas,
especifican requerimientos que están en conflicto con las necesidades de otros clientes o usuarios, o solicitan
requerimientos ambiguos o que no pueden someterse a prueba.
• Problemas de volatilidad. Los requerimientos cambian con el tiempo. Para controlar esto, se debe tener en
cuenta:
o Valorar el impacto en el negocio del sistema propuesto
o Definir el entorno técnico (arquitectura de computación, sistema operativo, necesidades de
telecomunicaciones) del sistema a desarrollar
o Identificar “restricciones de dominio” (características específicas del entorno de negocio en el dominio
de la aplicación) que limiten la funcionalidad y rendimientos del sistema o producto a construir
o Solicitar la participación de muchas personas para que los requisitos se definan desde diferentes puntos
de vista, asegurarse de identificar lo fundamental de cada requisito registrado
o Identificar requisitos ambiguos como candidatos para el modelo a emplear

¿Cuál es la finalidad de esta actividad dentro de la empresa? ¿Qué pasos se siguen para llevarla a cabo? ¿Quiénes los
realizan? ¿Cuánto tiempo tardan en efectuarlos? ¿Quiénes emplean la información resultante?

Elaboración. La información obtenida del cliente durante la concepción e indagación (a veces llamadas obtención) se
modela de forma que identifique los aspectos y comportamientos del software. La elaboración está motivada por la
creación y mejora de escenarios de usuario, que describan cómo interactuará el usuario final con el sistema.

Muchas veces también se utilizan casos de uso preliminares. Casos de uso: Su uso es común para la captura de
requisitos funcionales. Es la descripción de una acción o actividad. Define la forma en la que un actor utiliza un sistema
basado en computadora para alcanzar algún objetivo

De cada escenario se obtienen:

• Clases de análisis y sus atributos (entidades del dominio del negocio visibles para el usuario final).
• Se identifican relaciones y colaboraciones entre las clases.
• Se realizan diagramas UML complementarios, que definen el dominio de la Información, funciones y
comportamiento del problema.

Negociación. Es posible que los clientes pidan más de lo que puede lograrse teniendo en cuenta los recursos del
negocio, o que distintos clientes o usuarios propongan requerimientos conflictivos. Estos conflictos se resuelven
mediante una negociación. Se pide a clientes, usuarios y otros participantes que ordenen sus requerimientos según su
prioridad y que después analicen los conflictos. Con el empleo de un enfoque iterativo que da prioridad a los
requerimientos, se evalúa su costo y riesgo, algunos requerimientos se eliminan, combinan o modifican de modo que
cada parte logre cierto grado de satisfacción.

Especificación. Describe la función y características de un sistema de computación y las restricciones que gobiernan el
desarrollo. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo
matemático formal, un conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos. Para sistemas
grandes, el mejor enfoque puede ser un documento escrito que combine descripciones en un lenguaje natural con
modelos gráficos. La Especificación del Sistema es el producto final sobre los Requerimientos del Sistema, obtenido por
Ingeniería de requisitos.

Validación. Se evalúa la calidad de los productos generados. Se valida que los requisitos no sean ambiguos, que se
detectaron y corrigieron los errores, y que los productos del trabajo se presentan conforme a lo pedido. El mecanismo
principal de validación de los requerimientos es la revisión técnica. El equipo de revisión que los valida incluye
ingenieros de software, clientes, usuarios y otros participantes.

Gestión de cambios. Existe porque los requerimientos cambian a medida que se desarrolla el sistema. La gestión de
cambios son actividades que ayudan al equipo del proyecto a identificar, controlar y los requerimientos y a sus cambios
en cualquier momento del desarrollo del proyecto. Muchas de estas actividades son idénticas a las técnicas de
administración de gestión de configuración del software.

Modelo de análisis

Al terminar el análisis de requerimientos, el paso siguiente es transformar los requerimientos en un diseño que satisfaga
las necesidades de los clientes. Basado en este análisis, se generan las especificaciones del SW.

Combinación de texto y diagramas para representar los requisitos, las funciones y el comportamiento de manera fácil de
entender. “Puente” entre la descripción y el diseño. No siempre es posible una división clara de tareas de análisis y en el
modelado. De modo invariable, como parte del análisis se realiza algún diseño y algún análisis se efectúa durante el
diseño.

Cumplir 3 objetivos primarios:

1. Describir lo que requiere el cliente

2. Establecer una base para la creación de un diseño de SW.
3. Definir un Conjunto de Requisitos base que puedan validarse una vez construido el SW.

Reglas prácticas:

• Modelo centrado en requisitos visibles dentro del problema o dominio del negocio. Grado de abstracción alto
(sin detalles)
• Debe retrasarse la consideración de la Infraestructura y otros modelos no funcionales hasta el diseño (Ej: BD sin
clases, funciones o comportamientos)
• Minimizar el acoplamiento de todo el sistema en relación entre funciones y clases.
• Modelo lo más simple que sea posible.

Acoplamiento: es el grado de dependencia que tiene un componente con otros. Si existen muchas relaciones entre los
componentes, con muchas dependencias entre ellos, tendremos un grado de acoplamiento alto. Si los componentes son
independientes unos de otros, el acoplamiento será bajo.

Cohesión: que tan relacionadas están las partes de un mismo componente. Si hablamos de clases, una clase tendrá una
cohesión alta si sus métodos están relacionados entre sí, tienen una “temática” común, trabajan con tipos similares, etc.
Si pasamos a componentes de mayor tamaño, como paquetes o librerías, tendríamos una cohesión alta cuando las
clases que lo forman están muy relacionadas entre sí, con un objetivo claro y focalizado.

Alta cohesión: toda la info en una clase debe estar estrechamente relacionada y tener un objetivo común. Bajo
acoplamiento: cada clase tiene que ser lo más independiente posible, de forma que si se debe modificar alguna no habrá
repercusión en el resto, favoreciendo la reutilización

En el ejemplo: Caja está acoplado con pago y venta y se ocupa de crear instancias de ambos. Cuantas más operaciones
se le den a la clase caja irá perdiendo la cohesión mientras se satura, ya que tiene que crear ambas instancias cada vez.
El pago está directamente relacionado con la venta y tienen el mismo objetivo; por ende, unirlas (haciendo que venta
cree instancias de pago) mejoraría la cohesión y disminuiría el acoplamiento con caja.

Análisis del dominio: es la identificación, análisis y especificación de requisitos comunes de un dominio especifico de
aplicación para, de manera típica, reutilizarlos en múltiples proyectos dentro de ese dominio de aplicación.

la meta del análisis de dominio es encontrar cosas comunes entre proyectos para poder reutilizase.

Modelo de datos:

El modelado de análisis usualmente inicia con el modelado de datos, en el que se define todos los objetos de datos que
se procesan dentro del sistema y las relaciones entre los objetos de datos.

Objeto de datos: Representación de cualquier información compuesta que el SW debe entender: entidad externa, cosa,
papel, evento o estructura.

Se trata de pensar de modo abstracto, acerca del problema empleando conceptos del mundo real y no conceptos de
computadoras.

• Modelo de escenario: Escritura de casos de uso. Trata de entender cómo desean interactuar los usuarios finales
con un sistema. Se puede realizar un diagrama de casos de uso preliminar. Desarrollo Diagrama de actividad
complementan CU representación gráfica del flujo de interacción dentro de un escenario, mostrando quien
tiene la responsabilidad de la acción
• Modelo de clases/Orientado a objetos: definir todas las clases (Relaciones y Comportamiento) relevantes para el
problema. Representa los objetos que manipulará el sistema, las operaciones (también llamadas métodos o
servicios) que se aplicarán a los objetos para efectuar la manipulación, las relaciones (algunas de ellas
jerárquicas) entre los objetos.
Se comienza por identificar las clases mediante el análisis de los escenarios de uso desarrollados como parte del
modelo de requerimientos. Diagramas clase, colaboración. Para ilustrar cómo podrían definirse las clases del
análisis durante las primeras etapas del modelado, considere un análisis de una narración de procesamiento
• Modelado de Flujo: Visión del Sistema tipo E – P – S. Es decir, los objetos de datos entran al sistema, son
transformados por elementos de procesamiento y los objetos de datos que resultan de ello salen del software.
Representación jerárquica porque el primer modelo de flujo de datos (en ocasiones llamado DFD de nivel 0 o
diagrama de contexto, el ej) representa al sistema como un todo. Los diagramas posteriores de flujo de datos
mejoran el diagrama de contexto y dan cada vez más detalles en los niveles siguientes. Aplicaciones que están
guiadas por eventos y no datos, que producen información de control.
• Modelo de comportamiento: (Diagrama de Estado, Diagrama de Secuencia) En vez de representar los elementos
de forma estática, muestra el comportamiento dinámico del sistema o producto. Para hacerlo, dicho
comportamiento se representa como función de eventos y tiempo específicos. El modelo de comportamiento
indica la forma en la que responderá el software a eventos o estímulos externos. Identifica los eventos que
Diagramas de estado para clases de análisis: representa los estados activos para cada clase y los eventos que
ocasionan cambios de estos estados activos Diagrama de secuencias Indican como los eventos causan
transiciones de un objeto a otro.