Post on 29-Mar-2016
description
INGENIERÍA DEL SOFTWARE
C A P Í T U L O 2 : M É T O D O S
C O N V E N C I O N A L E S P A R A L A
I N G E N I E R Í A D E L S O F T W A R E
I S T P - K H I P U
W I L B E R T D A L G U E R R E
O R D Ó Ñ E Z
2 0 1 3 - I
SESIÓN NÚMERO 10
INGENIERÍA DE
SISTEMAS Conocer el Proceso de la Ingeniería de Sistemas.
Ingeniería de Sistemas
1
Contenido
INGENIERÍA DE SISTEMAS .......................................................................... 2
LA JERARQUÍA DE LA INGENIERÍA DE SISTEMAS .................................................................. 5
Modelado del sistema .......................................................................................................... 5
Simulación del sistema ......................................................................................................... 7
INGENIERÍA DEL PROCESO DEL NEGOCIO ............................................................................ 8
INGENIERÍA DEL PRODUCTO .............................................................................................. 10
INGENIERÍA DE REQUISITOS ............................................................................................... 12
1. Identificación de requisitos ........................................................................................ 12
2. Análisis y negociación de requisitos ........................................................................... 14
3. Especificación de requisitos ....................................................................................... 15
4. Modelado del sistema ................................................................................................ 15
5. Validación de requisitos ............................................................................................. 16
MODELADO DEL SISTEMA .................................................................................................. 17
BIBLIOGRAFÍA ................................................................................................................ 21
Ingeniería de Sistemas
2
INGENIERÍA DE SISTEMAS
La ingeniería del software aparece
como consecuencia de un
proceso denominado
ingeniería de sistemas. En
lugar de centrarse
únicamente en el software, la
ingeniería de sistemas se
centra en diversos elementos,
analizando, diseñando y
organizando esos elementos en
un sistema que pueden ser un producto, un servicio
o una tecnología para la transformación de información o
control de información.
El proceso de ingeniería de sistemas es denominado ingeniería de procesos
de negocio cuando el contexto del trabajo de ingeniería se enfoca a una
empresa. Cuando hay que construir un producto, el proceso se denomina
ingeniería de producto.
Tanto la ingeniería de proceso de negocio como la de producto intentan
poner orden al desarrollo de sistemas basados en computadoras. Aunque
cada una se aplica en un dominio de aplicación diferente, ambas intentan
poner al software en su contexto.
La palabra sistema es posiblemente el término más usado y abusado del
léxico técnico. Hablamos de sistemas políticos y de sistemas educativos, de
sistemas de aviación y de sistemas de fabricación, de sistemas bancarios y
de sistemas de locomoción. La palabra no nos dice gran cosa. Usamos el
adjetivo para describir el sistema y para entender el contexto en que se
emplea.
El diccionario Webster define sistema como:
1. Un conjunto o disposición de cosas relacionadas de manera que
forman una unidad o un todo orgánico;
Ingeniería de Sistemas
3
2. Un conjunto de hechos, principios, reglas, etc., clasificadas y
dispuestas de manera ordenada mostrando un plan lógico de unión
de las partes;
3. Un método o plan de clasificación o disposición;
4. Una manera establecida de hacer algo; método; procedimiento.
Tomando prestada la definición del diccionario Webster, definimos un
sistema basado en computadora como: Un conjunto o disposición de
elementos que están organizados para realizar un objetivo predefinido
procesando información. El objetivo puede ser soportar alguna función de
negocio o desarrollar un producto que pueda venderse para generar
beneficios. Para conseguir el objetivo, un sistema basado en computadora
hace uso de varios elementos del sistema:
Software. Programas de computadora, estructuras de datos y su
documentación que sirven para hacer efectivo el método lógico,
procedimiento o control requerido.
Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo,
dispositivos de interconexión (por ejemplo, conmutadores de red,
dispositivos de telecomunicación) y dispositivos electromecánicos (por
ejemplo, sensores, motores, bombas) que proporcionan una función
externa, del mundo real.
Personas. Usuarios y operadores del hardware y software.
Documentación. Manuales, formularios y otra información descriptiva que
plasma el empleo y/o funcionamiento del sistema.
Procedimientos. Los pasos que definen el empleo específico de cada
elemento del sistema o el contexto procedimental en que reside el sistema.
Los elementos se combinan de varias maneras para transformar la
información. Por ejemplo, un departamento de marketing transforma la
información bruta de ventas en un perfil del típico comprador del producto;
un robot transforma un archivo de órdenes, que contiene instrucciones
específicas, en un conjunto de señales de control que provocan alguna
acción física específica. Tanto la creación de un sistema de información para
asesorar a un departamento de marketing, como el software de control para
el robot, requieren de la ingeniería de sistemas.
Ingeniería de Sistemas
4
Una característica complicada de los sistemas basados en computadora es
que los elementos que componen un sistema pueden también representar
un macro elemento de un sistema aún más grande. El macro elemento es un
sistema basado en computadora que es parte de un sistema más grande
basado en computadora. Por ejemplo, consideremos un «sistema de
automatización de una fábrica» que es esencialmente una jerarquía de
sistemas. En el nivel inferior de la jerarquía tenemos una máquina de control
numérico, robots y dispositivos de entrada de información.
Cada uno es un sistema basado en computadora por
derecho propio.
Los elementos de la máquina de control numérico incluyen hardware
electrónico y electromecánico (por ejemplo, procesador y
memoria, motores, sensores); software (para
comunicaciones, control de la máquina e interpolación);
personas (el operador de la máquina); una base de datos
(el programa almacenado); documentación y
procedimientos.
En el siguiente nivel de la jerarquía, se define una célula de
fabricación. La célula de fabricación es un sistema basado
en computadora que puede tener elementos propios (por
ejemplo, computadoras, fijaciones mecánicas) y también
integra los macro elementos que hemos denominado
máquina de control numérico, robot y dispositivo de entrada de información.
Para resumir, la célula de fabricación y sus macro elementos están
compuestos de elementos del sistema con las etiquetas genéricas: software,
hardware, personas, base de datos, procedimientos y documentación.
En algunos casos, los macro elementos pueden compartir un elemento
genérico. Por ejemplo, el robot y la máquina podrían ser manejadas por el
mismo operador (el elemento personas). En otros casos, los elementos
genéricos son exclusivos de un sistema.
Se podría aplicar una
descomposición
similar a los
dispositivos de
entrada de
información y al robot.
Todos son sistemas
basados en
computadora.
Ingeniería de Sistemas
5
El papel del ingeniero de sistemas es definir los elementos de un sistema
específico basado en computadora en el contexto de la jerarquía global de
sistemas (macro elementos).
LA JERARQUÍA DE LA INGENIERÍA DE SISTEMAS
La ingeniería de sistemas comprende una colección de métodos para
navegar de arriba abajo y de abajo arriba en las siguientes
características. El proceso de la ingeniería de sistemas empieza
normalmente con una «visión global». Es decir, se examina el dominio
entero del negocio o del producto para asegurarse de que se puede
establecer el contexto de negocio o tecnológico apropiado. La visión
global se refina para enfocarse totalmente en un dominio de interés
específico. Dentro de un dominio específico, se analiza la necesidad
de elementos del sistema (por ejemplo, información, software,
hardware, personas). Finalmente, se inicia el análisis, diseño y
construcción del elemento del sistema deseado. En la parte alta de la
jerarquía se establece un contexto muy amplio y en la parte baja se
llevan a cabo actividades técnicas detalladas, realizadas por la
disciplina de ingeniería correspondiente (por ejemplo, ingeniería
hardware o software)
Modelado del sistema
La ingeniería de sistemas de computadora es un proceso de
modelado. Tanto si el punto de mira está en la visión global o en la
visión detallada, el ingeniero crea modelos que:
1. Definan los procesos que satisfagan las necesidades de la visión
en consideración;
2. representen el comportamiento de los procesos y los supuestos
en los que se basa el comportamiento;
3. definan explícitamente las entradas exógenas y endógenas de
información al modelo;
4. representen todos las uniones (incluyendo las salidas) que
permitan al ingeniero entender mejor la visión.
Para construir un modelo del sistema, el ingeniero debería considerar
algunas restricciones:
Ingeniería de Sistemas
6
1. Supuestos que reducen el número de permutaciones y
variaciones posibles, permitiendo así al modelo reflejar el
problema de manera razonable. Por ejemplo, considere un
producto de representación en tres dimensiones usado por la
industria de entretenimiento para crear animaciones realistas. Un
dominio del producto permite la representación de formas
humanas en 3D. Las entradas a este dominio comprenden la
habilidad de introducir movimiento de un «actor» humano vivo,
desde vídeo o creando modelos gráficos. El ingeniero del sistema
hace ciertos supuestos sobre el rango de movimientos humanos
permitidos (por ejemplo, las piernas no pueden enrollarse
alrededor del tronco) de manera que puede limitarse el proceso y
el rango de entradas.
2. Simplificaciones que permiten crear el modelo a tiempo. Para
ilustrarlo, considere una compañía de productos de oficina que
vende y suministra una amplia variedad de fotocopiadoras, faxes
y equipos similares. El ingeniero del sistema está modelando las
necesidades de la organización suministradora y está trabajando
para entender el flujo de información que engendra una orden de
suministro. Aunque una orden de suministro puede generarse
desde muchos orígenes, el ingeniero categoriza solamente dos
fuentes: demanda interna o petición externa. Esto permite una
partición simplificada de entradas necesaria para generar una
orden de trabajo.
3. Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se
está modelando un sistema de aviónica para un avión de próxima
generación. Como el avión tendrá un diseño de dos motores,
todos los dominios de supervisión de la propulsión se modelarán
para albergar un máximo de dos motores y sus sistemas
redundantes asociados.
4. Restricciones que guían la manera de crear el modelo y el
enfoque que se toma al implementar el modelo. Por ejemplo, la
infraestructura tecnológica para el sistema de representación en
tres dimensiones descrita anteriormente es un solo procesador
basado en un Power-PC. La complejidad de cálculo de los
problemas debe restringirse para encajar en los límites de
proceso impuestos por el procesador.
Ingeniería de Sistemas
7
5. Preferencias que indican la arquitectura preferida para todos los
datos, funciones y tecnología. La solución preferida entra a veces
en conflicto con otros factores restrictivos. Aunque la satisfacción
del cliente es a menudo tomada en cuenta hasta el punto de
realizar su enfoque preferido. El modelo de sistema resultante
(desde cualquier visión) puede reclamar una solución
completamente automática, semiautomática o un enfoque manual.
De hecho, es posible a menudo caracterizar modelos de cada tipo
que sirven de soluciones alternativas para el problema que
tenemos entre manos. En esencia, el ingeniero del sistema
modifica simplemente la influencia relativa de los diferentes
elementos del sistema (personas, hardware, software) para crear
modelos de cada tipo.
Simulación del sistema
En los años 60, R.M. Graham hizo un comentario crítico sobre la
manera en que se construían los sistemas basados en computadora:
«Construimos sistemas igual que los hermanos Wright construían
aviones: construimos todo el sistema, lo empujamos barranco abajo,
le dejamos que se estrelle y empezamos de nuevo.» De hecho, para
al menos un tipo de sistema (el sistema reactivo) lo continuamos
haciendo hoy en día. Muchos sistemas basados en computadora
interaccionan con el mundo real de forma reactiva. Es decir, los
acontecimientos del mundo real son vigilados por el hardware y el
software que componen el sistema, y basándose en esos sucesos, el
sistema aplica su control sobre las máquinas, procesos e incluso las
personas que motivan los acontecimientos. Los sistemas de tiempo
real y sistemas empotrados pertenecen a menudo a la categoría de
sistemas reactivos. Desgraciadamente, los desarrolladores de
sistemas reactivos luchan a veces para hacerlos funcionar
correctamente. Hasta hace poco, ha sido difícil predecir el
rendimiento, la eficacia y el comportamiento de estos sistemas antes
de construirlos. Realmente, la construcción de muchos sistemas de
tiempo real era una aventura. Las sorpresas (la mayoría
desagradables) no se descubrían hasta que el sistema era construido
y «arrojado colina abajo». Si el sistema se estrellaba debido a un
funcionamiento incorrecto, comportamiento inapropiado o escaso
rendimiento, cogíamos las piezas y empezábamos de nuevo. Muchos
sistemas de la categoría de los reactivos controlan máquinas y/o
procesos (por ejemplo, aerolíneas comerciales o refinerías de
Ingeniería de Sistemas
8
petróleo) que deben operar con extrema fiabilidad. Si el sistema falla,
podrían ocurrir pérdidas económicas o humanas significativas. Por
este motivo, el enfoque descrito por Graham es penoso y peligroso.
Hoy en día se utilizan herramientas software para el modelado y
simulación de sistemas para ayudar a eliminar sorpresas cuando se
construyen sistemas reactivos basados en computadora. Estas
herramientas se aplican durante el proceso de ingeniería de sistemas,
mientras se están especificando las necesidades del hardware,
software, bases de datos y de personas. Las herramientas de
modelado y simulación capacitan al ingeniero de sistemas para probar
una especificación del sistema.
INGENIERÍA DEL PROCESO DEL NEGOCIO
El objetivo de la ingeniería de
proceso de
negocio (IPN) es
definir arquitecturas
que permitan a las
empresas emplear la
información
eficazmente. Michael
Guttman describe el desafío cuando dice: El
actual entorno computacional consiste en un poder de
computación distribuido en toda la empresa con múltiples unidades
diferentes de procesamiento, dividido y configurado por una amplia
variedad de tareas, Nuevos planteamientos como la computación
cliente-servidor, procesamiento distribuido, el trabajo en red (por
nombrar algunos de los términos más sobreusados) permiten
gestionar las demandas aportando mayor funcionalidad y flexibilidad.
Sin embargo, el coste de estos cambios es ampliamente discutido por
las organizaciones de TI (Tecnologías de la Información) que deben
soportar esta políglota configuración. Hoy, cada organización de TI
debe favorecer la integración de sus sistemas. Debe diseñar,
implementar y soportar su propia configuración de recursos de
computación heterogénea, distribuidos lógica y geográficamente por
toda la empresa, conectándola a través de un esquema apropiado
para el trabajo en red. Por otra parte, esta configuración debe ser
diseñada para cambios continuos, desigualmente localizados en la
Ingeniería de Sistemas
9
empresa, debido a cambios en requisitos del negocio y en las propias
tecnologías. Estos diversos e incrementales cambios deben ser
coordinados a través del entorno distribuido, consistente en hardware
y software suministrado por decenas, cuando no cientos, de
vendedores. Por supuesto, esperamos que estos cambios los
incorporemos sin ruptura con la operativa habitual permitiendo
además ampliar la operativa. Cuando hablamos de una visión general
de las necesidades de tecnología de información de una compañía,
existen pequeñas incertidumbres que son planteadas a ingeniería de
sistemas. La ingeniería de proceso de negocio es un acercamiento
para crear un plan general para implementar la arquitectura de
computación se deben analizar y diseñar tres arquitecturas diferentes
dentro del contexto de objetivos y metas de negocio: arquitectura de
datos arquitectura de aplicaciones infraestructura de la tecnología
La arquitectura de datos proporciona una estructura para las
necesidades de información de un negocio o de una función de
negocio. Los ladrillos de la arquitectura son los objetos de datos que
emplea la empresa. Un objeto de datos contiene un conjunto de
atributos que definen aspectos, cualidades, características o
descriptor de los datos que han sido descritos. Por ejemplo, un
ingeniero de la información puede definir el objeto de datos: cliente.
Para describir más en detalle al cliente, se definen los siguientes
atributos:
Objeto: Cliente
Atributos: nombre
nombre de la compañía
clasificación del trabajo y autoridad en compra
dirección comercial e información de contacto
producto(s) de interés
compra(s) anteriores
fecha de último contacto
situación del contacto
Una vez definido el conjunto de datos, se identifican sus relaciones.
Una relación indica como los objetos están conectados. Como
ejemplo, considerar los objetos: cliente y producto A. Los dos objetos
Ingeniería de Sistemas
10
pueden conectarse por la relación compra; es decir, un cliente compra
el producto A o el producto A es comprado por un cliente.
Los objetos de datos (pueden existir cientos o miles las funciones de
negocio, están organizados dentro de una base de datos y se
transforman para proveer información que sirva a las necesidades del
negocio.
La arquitectura de aplicación comprende aquellos elementos de un
sistema que transforman objetos dentro de la arquitectura de datos
por algún propósito del negocio. En el contexto de este libro,
consideramos normalmente que la arquitectura de aplicación es el
sistema de programas (software) que realiza esta transformación. Sin
embargo, en un contexto más amplio, la arquitectura de aplicación
podría incorporar el papel de las personas (por ejemplo, cliente
servidor) que ha sido diseñado para implementar estas tecnologías.
La infraestructura tecnológica proporciona el fundamento de las
arquitecturas de datos y de aplicaciones. La infraestructura
comprende el hardware y el software empleados para dar soporte a
las aplicaciones y datos. Esto incluye computadoras y redes de
computadora, enlaces de telecomunicaciones, tecnologías de
almacenamiento y la arquitectura (por ejemplo, cliente servidor)
diseñada para implementar estas tecnologías.de las arquitecturas de
datos y de aplicaciones. La infraestructura comprende el hardware y
el software empleados para dar soporte a las aplicaciones y datos.
Esto incluye computadoras y redes de computadora, enlaces de
telecomunicaciones, tecnologías de almacenamiento y la arquitectura
(por ejemplo, cliente servidor) diseñada para implementar estas
tecnologías.
INGENIERÍA DEL PRODUCTO
La meta de la ingeniería de producto es traducir el deseo de un
cliente, de un conjunto de capacidades definidas, a un producto
operativo. Para conseguir esta meta, la ingeniería de producto (como
la ingeniería de proceso de negocio) debe crear una arquitectura y
una infraestructura. La arquitectura comprende cuatro componentes
de sistema distintos: software, hardware, datos (bases de datos) y
personas.
Ingeniería de Sistemas
11
Se establece una infraestructura de soporte e incluye la tecnología
requerida para unir los componentes y la información (por ejemplo,
documentos, CD-ROM, vídeo) que se emplea para dar soporte a los
componentes. La visión global se consigue a través de la ingeniería
de requisitos. Los requisitos generales del producto se obtienen del
cliente. Estos requisitos comprenden necesidades de información y
control, funcionalidad del producto y comportamiento, rendimiento
general del producto, diseño, restricciones de la interfaz y otras
necesidades especiales. Una vez que se conocen estos requisitos, la
misión del análisis del sistema es asignar funcionalidad y
comportamiento a cada uno de los cuatro componentes mencionados
anteriormente.
Una vez que se ha hecho la asignación, comienza la ingeniería de
componentes del sistema. La ingeniería de componentes del sistema
es, de hecho, un conjunto de actividades
concurrentes que se dirigen separadamente a
cada uno de los componentes del sistema: la
ingeniería del software, ingeniería hardware,
ingeniería humana e ingeniería de bases de datos.
Cada una de estas disciplinas de ingeniería toma
una vista de dominio específica, pero es
importante resaltar que las disciplinas de ingeniería
deben establecer y mantener una comunicación
activa entre ellas. Parte del papel del análisis de
sistemas es establecer los mecanismos de interfaz
que permitirán que esto suceda.
La visión de elemento para la ingeniería de
producto es la disciplina de ingeniería aplicada a la
asignación de componentes. Para la ingeniería del
software, esto significa actividades de modelado
del análisis y diseño y actividades de construcción
e integración que comprenden generación de
código, pruebas y actividades de soporte. El
modelado de la fase de análisis asigna requisitos a las
representaciones de datos, funciones y comportamiento.
El diseño convierte
el modelo de
análisis en diseños
de datos,
arquitectónicos, de
interfaz y a nivel de
componentes del
software.
Ingeniería de Sistemas
12
INGENIERÍA DE REQUISITOS
La consecuencia del
proceso de
ingeniería de
sistemas es la
especificación de un
sistema o producto
basado en
computadora que se
describe genéricamente,
en diferentes niveles. Pero
el desafío de la ingeniería
del sistema (y de los
ingenieros del software) es
importante: ¿Cómo podemos
asegurar que hemos especificado un
sistema que recoge las necesidades del cliente y satisface sus
expectativas? No hay una respuesta segura a esta difícil pregunta,
pero un sólido proceso de ingeniería de requisitos es la mejor solución
de que disponemos actualmente. La ingeniería de requisitos facilita el
mecanismo apropiado para comprender lo que quiere el cliente,
analizando 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. El proceso de ingeniería de
requisitos puede ser descrito en 5 pasos distintos:
1. Identificación de Requisitos,
2. Análisis de Requisitos y Negociación,
3. Especificación de Requisitos,
4. Modelado del Sistema,
5. Validación de Requisitos y Gestión de Requisitos.
1. Identificación de requisitos
En principio, parece bastante simple preguntar al cliente, a los
usuarios y a los que están involucrados en los objetivos del sistema o
producto y sean expertos, investigar cómo los sistemas o productos
se ajustan a las necesidades del negocio, y finalmente, cómo el
Ingeniería de Sistemas
13
sistema o producto va a ser utilizado en el día a día. Esto que parece
simple, es muy complicado. Christel y Kang identifican una serie de
problemas que nos ayudan a comprender por qué la obtención de
requisitos es costosa. 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 comprensión. Los
clientes/usuarios no están completamente seguros de lo que
necesitan, tienen una pobre compresión de las capacidades y
limitaciones de su entorno de computación, no existe un total
entendimiento del dominio del problema, existen dificultades para
comunicar las necesidades al ingeniero del sistema, la omisión de
información por considerar que es «obvia», especificación de
requisitos que están en conflicto con las necesidades de otros
clientes/usuarios, o especificar requisitos ambiguos o poco estables.
Problemas de volatilidad. Los requisitos cambian con el tiempo.
Para ayudar a solucionar estos problemas, los ingenieros de sistemas
deben aproximarse de una manera organizada a través de reuniones
para definir requisitos. Sommerville y Sawyer sugieren un conjunto de
actuaciones para la obtención de
requisitos, que están descritos en las
tareas siguientes: valorar el impacto en el
negocio y la viabilidad técnica del sistema
propuesto; identificar las personas que
ayudarán a especificar requisitos y
contrastar su papel en la organización;
definir el entorno técnico (arquitectura de
computación, sistema operativo,
necesidades de telecomunicaciones) en el
sistema o producto a desarrollar e integrar;
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; definir uno
o más métodos de obtención de requisitos
(entrevistas, grupos de trabajo, equipos de
discusión); 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; identificar requisitos
Cada uno de los
productos
obtenidos debe ser
revisado por las
personas que
hayan participado
en la obtención de
sus requisitos.
Ingeniería de Sistemas
14
ambiguos como candidatos para el prototipo, y crear escenarios de
uso para ayudar a los clientes/usuarios a identificar mejor los
requisitos fundamentales.
El resultado alcanzado como consecuencia de la identificación de
requisitos variará dependiendo del tamaño del sistema o producto a
construir. Para grandes sistemas, el producto obtenido debe incluir:
una relación de necesidades y características; un informe conciso del
alcance del sistema o producto; una lista de clientes, usuarios y otros
intervinientes que deben participar en la actividad de obtención de
requisitos; una descripción del entorno técnico del sistema; una
relación de requisitos (perfectamente agrupados por funcionalidad) y
las restricciones del dominio aplicables a cada uno; un conjunto de
escenarios que permiten profundizar en el uso del sistema o producto
bajo diferentes condiciones operativas, y cualquier prototipo
desarrollado para definir mejor los requisitos.
2. Análisis y negociación de requisitos
Una vez recopilados los requisitos, el producto obtenido configura la
base del análisis de requisitos. Los requisitos se agrupan por
categorías y se organizan en subconjuntos, se estudia cada requisito
en relación con el resto, se examinan los requisitos en su
consistencia, completitud y ambigüedad, y se clasifican en base a las
necesidades de los clientes/usuarios. Al iniciarse la actividad del
análisis de requisitos se plantean las siguientes cuestiones: ¿Cada
requisito es consistente con los objetivos generales del
sistema/producto? ¿Tienen todos los requisitos especificados el nivel
adecuado de abstracción? Es decir, ¿algunos requisitos tienen un
nivel de detalle técnico inapropiado en esta etapa? ¿El requisito es
necesario o representa una característica añadida que puede no ser
esencial a la finalidad del sistema? ¿Cada requisito está delimitado y
sin ambigüedad? Cada requisito tiene procedencia. Es decir, ¿existe
un origen (general o específico) conocido para cada requisito?
¿Existen requisitos incompatibles con otros requisitos? ¿Es posible
lograr cada requisito en el entorno técnico donde se integrará el
sistema o producto? ¿Se puede probar el requisito una vez
implementado?
El ingeniero del sistema debe resolver estos conflictos a través de un
proceso de negociación. Los clientes, usuarios y el resto de
Ingeniería de Sistemas
15
intervinientes deberán clasificar sus requisitos y discutir los posibles
conflictos según su prioridad. Los riesgos asociados con cada
requisito serán identificados y analizados. Se efectúan
«estimaciones» del esfuerzo de desarrollo que se utilizan para valorar
el impacto de cada requisito en el coste del proyecto y en el plazo de
entrega. Utilizando un procedimiento iterativo, se irán eliminando
requisitos, se irán combinando y/o modificando para conseguir
satisfacer los objetivos planteados.
3. Especificación de requisitos
En el contexto de un sistema basado en computadoras (y software), el
término especificación significa distintas cosas para diferentes
personas. Una especificación puede ser un documento escrito, un
modelo gráfico, un modelo matemático formal, una colección de
escenarios de uso, un prototipo o una combinación de lo
anteriormente citado.
Algunos sugieren que debe desarrollarse una «plantilla estándar» y
usarse en la especificación del sistema, argumentando que así se
conseguirían requisitos que sean presentados de una forma más
consistente y más comprensible. No obstante, en muchas ocasiones
es necesario buscar la flexibilidad cuando una especificación va a ser
desarrollada. Para grandes sistemas, un documento escrito,
combinado con descripciones en lenguajes natural y modelos gráficos
puede ser la mejor alternativa. En cualquier caso, los escenarios a
utilizar pueden ser tanto los requeridos para productos de tamaño
pequeño o los de sistemas que residan en entornos técnicos bien
conocidos.
4. Modelado del sistema
Considere por un momento que a usted se le ha requerido para
especificar los requisitos para la construcción de una cocina. Se
conocen las dimensiones del lugar, la localización de las puertas y
ventanas y el espacio de pared disponible. Debes especificar todos
los armarios y electrodomésticos e indicar dónde colocarlos. ¿Será
una especificación válida? La respuesta es obvia. Para especificar
completamente lo que vamos a desarrollar, necesitamos un modelo
Ingeniería de Sistemas
16
de la cocina con toda su información, esto es, un anteproyecto o una
representación en tres dimensiones que muestre las posiciones de los
armarios y electrodomésticos, y sus relaciones. Con el modelo será
relativamente fácil asegurar la eficiencia del trabajo (un requisito de
todas las cocinas), la estética «visual» de la sala (es un requisito
personal, aunque muy importante).
Se construyen modelos del sistema por la misma razón que
desarrollamos para una cocina un anteproyecto o una representación
en 3D. Es importante evaluar los componentes del sistema y sus
relaciones entre sí; determinar cómo están reflejados los requisitos, y
valorar como se ha concebido la «estética» en el sistema.
5. Validación de requisitos
El resultado del trabajo realizado es una consecuencia de la
ingeniería de requisitos (especificación del sistema e información
relacionada) y es evaluada su calidad en la fase de validación. La
validación de requisitos examina las especificaciones para asegurar
que todos los requisitos del sistema han sido establecidos sin
ambigüedad, sin inconsistencias, sin omisiones, que los errores
detectados hayan sido corregidos, y que el resultado del trabajo se
ajusta a los estándares establecidos para el proceso, el proyecto y el
producto.
El primer mecanismo para la validación de los requisitos es la revisión
técnica formal. El equipo de revisión incluye ingenieros del sistema,
clientes, usuarios, y otros intervinientes que examinan la
especificación del sistema buscando errores en el contenido o en la
interpretación, áreas donde se necesitan aclaraciones, información
incompleta, inconsistencias (es un problema importante), requisitos
contradictorios, o requisitos imposibles o inalcanzables.
Aunque la validación de requisitos puede guiarse de manera que se
descubran errores, es útil chequear cada requisito con un
cuestionario. Las siguientes cuestiones representan un pequeño
subconjunto de las preguntas que pueden plantearse:
¿Está el requisito claramente definido? ¿Puede interpretarse mal?
¿Está identificado el origen del requisito (por ejemplo: persona,
Ingeniería de Sistemas
17
norma, documento)? ¿El planteamiento final del requisito ha sido
contrastado con la fuente original? ¿El requisito está delimitado en
términos cuantitativos? ¿Qué otros requisitos hacen referencia al
requisito estudiado? ¿Están claramente identificados por medio de
una matriz de referencias cruzadas o por cualquier otro mecanismo?
¿El requisito incumple alguna restricción definida? ¿El requisito es
verificable? Si es así, ¿podemos efectuar pruebas (algunas veces
llamadas criterios de validación) para verificar el requisito? ¿Se puede
seguir el requisito en el modelo del sistema que hemos desarrollado?
¿Se puede localizar el requisito en el conjunto de objetivos del
sistema/producto? ¿Está el requisito asociado con los rendimientos
del sistema o con su comportamiento y han sido establecidas
claramente sus características operacionales? ¿El requisito está
implícitamente definido?
MODELADO DEL SISTEMA
Todos los sistemas basados
en computadora
pueden
modelarse como
una
transformación de
la información
empleando una
arquitectura del tipo
entrada-proceso-salida.
Hatley y Pirbhai han
extendido esta visión para
incluir dos características adicionales
del sistema: tratamiento de la interfaz de usuario y
tratamiento del mantenimiento y autocomprobación. Aunque estas
características adicionales no están presentes en todos los sistemas
basados en computadora, son muy comunes y su especificación hace
más robusto cualquier modelo del sistema. Mediante la
representación de entrada, proceso, salida, tratamiento de la interfaz
de usuario y de Auto comprobación, un ingeniero de sistemas puede
crear un modelo de componentes de sistema que establezca el
fundamento para análisis de requisitos posteriores y etapas de diseño
en cada una de las disciplinas de ingeniería.
Ingeniería de Sistemas
18
Para desarrollar el modelo de sistema, se emplea un esquema del
modelado del sistema. El ingeniero de sistemas asigna elementos a
cada una de las cinco regiones de tratamiento del esquema: (1)
interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema,
(4) salida y (5) mantenimiento y autocomprobación.
Como casi todas las técnicas de modelado usadas en la ingeniería del
software y de sistemas, el esquema del modelado del sistema permite
al analista crear una jerarquía en detalle. En la parte alta de la
jerarquía reside el diagrama de contexto del sistema (DCS). El
diagrama de contexto «establece el límite de información entre el
sistema que se está implementando y el entorno en que va a operar».
Es decir, el DCS define todos los suministradores externos de
información que emplea el sistema, todos los consumidores externos
de información creados por el sistema y todas las entidades que se
comunican a través de la interfaz o realizan mantenimiento y
autocomprobación.
Para ilustrar el empleo del DCS, considere una versión ampliada del
sistema de clasificación de cinta transportadora (SCCT). Al ingeniero
del sistema se le presenta la siguiente declaración (algo confusa) de
objetivos para el SCCT:
El sistema SCCT debe desarrollarse de manera que las cajas que se
mueven a lo largo de la cinta transportadora sean identificadas y
ordenadas en uno de los seis contenedores al final de la cinta. Las
cajas pasarán a través de una estación clasificadora donde se
identificarán. Basándose en un número de identificación impreso en
un lateral de la caja (se proporciona un código de barras equivalente),
las cajas se mandarán a los contenedores apropiados. Las cajas
pasan aleatoriamente y están igualmente espaciadas. La línea se
mueve lentamente.
Para este ejemplo, la versión ampliada utiliza un PC en la estación
clasificadora. El PC ejecuta todo el software del SCCT; interacciona
con el lector de código de barras para leer parte de los números de
cada caja; interacciona con la cinta transportadora vigilando los
equipos que controlan velocidad en dicha cinta; almacena todos los
números de pieza clasificados; interacciona con el operador de la
estación clasificadora para producir una variedad de informes y
diagnósticos; envía señales de control al hardware separador para
Ingeniería de Sistemas
19
clasificar las cajas; y se comunica con la estructura central de la
automatización de la fábrica.
En la Figura se muestra el DCS para SCCT (ampliado).
Cada caja de la Figura representa una entidad externa, es decir, un
suministrador o consumidor de información del sistema. Por ejemplo,
el lector del código de barras produce información que es introducida
en el sistema SCCT. El símbolo para representar todo el sistema (o a
niveles más bajos, subsistemas principales) es un rectángulo con las
esquinas redondeadas. De ahí que SCCT se represente en la región
de proceso y control en el centro del DCS. Las flechas etiquetadas
mostradas en el DCS representan información (datos y control) que
va desde el entorno exterior al sistema SCCT. La entidad externa
lector del código de barras produce una entrada de información
etiquetada como código de barras. En esencia, el DCS sitúa a
cualquier sistema en el contexto de su entorno exterior.
Ingeniería de Sistemas
20
El ingeniero de sistemas refina el diagrama de contexto de
arquitectura estudiando con más detalle el rectángulo sombreado de
la Figura. Se identifican los subsistemas principales que permiten
funcionar al sistema clasificador de cinta transportadora dentro del
contexto definido por el DCS.
En este punto, cada uno de los subsistemas puede contener uno o
más elementos del sistema (por ejemplo, hardware, software,
personas) tal y como los ha asignado el ingeniero de sistemas. El
diagrama inicial de flujo del sistema (DFS) se convierte en el nudo
superior de una jerarquía de DFS. Cada rectángulo redondeado del
DFS original puede expandirse en otra plantilla de arquitectura
dedicada exclusivamente a ella. Se pueden especificar (delimitar) los
subsistemas y la información que fluyen entre ellos para los
subsiguientes trabajos de ingeniería. Una descripción narrativa de
cada subsistema y una definición de todos los datos que fluyen entre
los subsistemas son elementos importantes de la Especificación del
Sistema.
Ingeniería de Sistemas
21
BIBLIOGRAFÍA
Ingeniería del software – un enfoque práctico. Roger S. Pressman
http://www.google.com.pe/search?num=10&hl=es&site=imghp&tb
m=isch&source=hp&biw=1366&bih=677&q=EL+PRODUCTO&oq=
EL+PRODUCTO&gs_l=img.3..0l10.1430.3454.0.4143.11.9.0.2.2.0
.186.986.4j5.9.0...0.0...1ac.1.Fl7oAV4lIQw#hl=es&tbo=d&site=img
hp&tbm=isch&sa=1&q=software+de+inteligencia+artificial&oq=soft
ware+de+inteligencia+artificial&gs_l=img.3..0j0i24l5.134002.1409
50.6.141169.26.11.0.15.15.1.196.1908.0j11.11.0...0.0...1c.1.9iim2
AMAFfQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=ba1326681ff2cb
8&bpcl=38897761&biw=1366&bih=634
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
http://www.ctic.uni.edu.pe/files/insoft01.pdf
Todos son links o enlaces a diferentes páginas web que se
consultaron para el desarrollo de esta sesión de clases.