ffabian88.files.wordpress.com · Web view1.1. Software y características del software El Software...
93
1. El software y la ingeniería del software 1.1. Software y características del software El Software La descripción de software en un libro de texto podría tomar la forma siguiente: el software es (1) instrucciones que cuando se ejecutan proporcionan la función y el rendimiento deseados, (2) estructuras de datos que permiten a los programas manipular adecuadamente la información, y (3) documentos que describen la operación y el uso de programas. Características del Software Para poder comprender lo que es el software (y consecuentemente la Ingeniería del Software), es importante examinar las características del software que lo diferencian de otras cosas que los hombres pueden construir. El software es un elemento del sistema que es lógico, en lugar de físico. Por lo tanto el software tiene unas características considerablemente distintas a las del hardware: 1. El software se desarrolla, no se fabrica en un sentido clásico. Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relación entre las personas dedicadas y el trabajo realizado
-
Upload
phungnguyet -
Category
Documents
-
view
232 -
download
0
Transcript of ffabian88.files.wordpress.com · Web view1.1. Software y características del software El Software...
1. El software y la ingeniería del software
1.1. Software y características del software
El Software
La descripción de software en un libro de texto podría tomar la forma siguiente: el software es
(1) instrucciones que cuando se ejecutan proporcionan la función y el rendimiento deseados, (2)
estructuras de datos que permiten a los programas manipular adecuadamente la información, y
(3) documentos que describen la operación y el uso de programas.
Características del Software
Para poder comprender lo que es el software (y consecuentemente la Ingeniería del Software),
es importante examinar las características del software que lo diferencian de otras cosas que los
hombres pueden construir.
El software es un elemento del sistema que es lógico, en lugar de físico. Por lo tanto el software
tiene unas características considerablemente distintas a las del hardware:
1. El software se desarrolla, no se fabrica en un sentido clásico. Aunque existen similitudes
entre el desarrollo del software y la construcción del hardware, ambas actividades son
fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante
un buen diseño, pero la fase de construcción del hardware puede introducir problemas de
calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades
dependen de las personas, pero la relación entre las personas dedicadas y el trabajo
realizado es completamente diferente para el software. Ambas actividades requieren de la
construcción de un producto, pero los métodos son diferentes.
2. Los costes del software se encuentran en la ingeniería. Esto significa que los proyectos de
software no se pueden gestionar como si fueran proyectos de fabricación.
3. El software no se estropea. El software no es susceptible a los males del entorno que hacen
que el hardware se estropee. Otro aspecto de ese deterioro ilustra la diferencia entre el
hardware y el software. Cuando un componente se estropea, se sustituye por una pieza de
repuesto. No hay pieza de repuesto para el software. Cada fallo en el software indica un
error en el diseño o en el proceso mediante el que se tradujo el diseño a código maquina
ejecutable. Por tanto, el mantenimiento del software tiene una complejidad
considerablemente mayor que la del mantenimiento del hardware.
4. La mayoría del software se construye a medida, en vez de ensamblar componentes
existentes. No existen catálogos de componentes de software. Se puede comprar software
ya desarrollado, pero solo como una unidad completa, no como componentes que pueden
reensamblarse en nuevos programas.
Importante para un componente de software de alta calidad. El componente debería diseñarse
1.2. Evolución. La crisis del software
La evolución del Software
Durante los primeros años de la era de la computadora, el software se contemplaba como un
añadido. La programación de computadoras era un "arte de andar por casa" para el que existían
pocos métodos sistemáticos. El desarrollo del software se realizaba virtualmente sin ninguna
planificación, hasta que los planes comenzaron a descalabrarse y los costes a correr. Los
programadores trataban de hacer las cosas bien, y con un esfuerzo heroico, a menudo salían con
éxito. El software se diseñaba a medida para cada aplicación y tenia una distribución
relativamente pequeña.
La mayoría del software se desarrollaba y era utilizado por la misma persona u organización. La
misma persona lo escribía, lo ejecutaba y, si fallaba, lo depuraba. Debido a este entorno
personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien
y, la documentación normalmente no existía.
La segunda era en la evolución de los sistemas de computadora se extienden desde la mitad de
la década de los sesenta hasta finales de los setenta. La multiprogramación y los sistemas
multiusuario introdujeron nuevos conceptos de interacción hombre - maquina. Las técnicas
interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticación del
hardware y del software. Los sistemas de tiempo real podían recoger, analizar y transformar
datos de múltiples fuentes, controlando así los procesos y produciendo salidas en milisegundos
en lugar de minutos. Los avances en los dispositivos de almacenamiento en línea condujeron a
la primera generación de sistemas de gestión de bases de datos.
La segunda era se caracterizo también por el establecimiento del software como producto y la
llegada de las "casas del software". Los patronos de la industria, del gobierno y de la
universidad se aprestaban a "desarrollar el mejor paquete de software" y ganar así mucho
dinero.
Conforme crecía el numero de sistemas informáticos, comenzaron a extenderse las bibliotecas
de software de computadora. Las casas desarrollaban proyectos en los que se producían
programas de decenas de miles de sentencia fuente. Todos esos programas, todas esas
sentencias fuente tenían que ser corregidos cuando se detectaban fallos, modificados cuando
cambiaban los requisitos de los usuarios o adaptados a nuevos dispositivos hardware que se
hubieran adquirido. Estas actividades se llamaron colectivamente mantenimiento del software.
La tercera era en la evolución de los sistemas de computadora comenzó a mediados de los años
setenta y continuo mas allá de una década. El sistema distribuido, múltiples computadoras, cada
una ejecutando funciones concurrentes y comunicándose con alguna otra, incrementó
notablemente la complejidad de los sistemas informáticos. Las redes de área local y de área
global, las comunicaciones digitales de alto ancho de banda y la creciente demanda de acceso
"instantáneo" a los datos, supusieron una fuerte presión sobre los desarrolladores del software.
La conclusión de la tercera era se caracterizo por la llegada y amplio uso de los
microprocesadores. El microprocesador ha producido un extenso grupo de productos
inteligentes, desde automóviles hasta hornos microondas, desde robots industriales a equipos de
diagnósticos de suero sanguíneo.
La cuarta era de la evolución de los sistemas informáticos se aleja de las computadoras
individuales y de los programas de computadoras, dirigiéndose al impacto colectivo de las
computadoras y del software. Potentes maquinas personales controladas por sistemas
operativos sofisticados, en redes globales y locales, acompañadas por aplicaciones de software
avanzadas se han convertido en la norma.
La industria del software ya es la cuna de la economía del mundo. Las técnicas de la cuarta
generación para el desarrollo del software están cambiando en la forma en que la comunidad del
software construye programas informáticos. Las tecnologías orientadas a objetos están
desplazando rápidamente los enfoques de desarrollo de software más convencionales en muchas
áreas de aplicaciones.
Sin embargo, un conjunto de problemas relacionados con el software ha persistido a través de la
evolución de los sistemas basados en computadora, y estos problemas continúan aumentando.
1. los avances del software continúan dejando atrás nuestra habilidad de construir software
para alcanzar el potencial del hardware.
2. Nuestra habilidad de construir nuevos programas no pueden ir al mismo ritmo de la
demanda de nuevos programas, ni podemos construir programas lo suficientemente rápido
como para cumplir las necesidades del mercado y de los negocios.
3. El uso extenso de computadoras ha hecho de la sociedad cada vez más dependiente de la
operación fiable del software. Cuando el software falla, pueden ocurrir daños económicos
enormes y ocasionar sufrimiento humano.
4. Luchamos por construir software informático que tengan fiabilidad y alta calidad.
5. Nuestra habilidad de soportar y mejorar los programas existentes se ve amenazada por
diseños pobres y recursos inadecuados.
En respuesta a estos problemas, las practicas de la Ingeniería del Software se están adoptando
en toda la industria.
Crisis del software
La crisis del software se fundamentó en el tiempo de creación de software, ya que en la
creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca
flexibilidad.
Es un término informático acuñado en 1968, en la primera conferencia organizada por la OTAN
sobre desarrollo de software, de la cual nació formalmente la rama de la ingeniería de software.
El término se adjudica a F. L. Bauer, aunque previamente había sido utilizado por Edsger
Dijkstra en su obra The Humble Programmer.
Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de
defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la
complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver
sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.
Además, no existen todavía herramientas que permitan estimar de una manera exacta, antes de
comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este
hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará un
proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente no se cumplen
por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se
incrementa con la esperanza de disminuir el plazo de ejecución.
Por último, las aplicaciones de hoy en día son programas muy complejos, inabordables por una
sola persona. En sus comienzos se valoró como causa también la inmadurez de la ingeniería de
software, aunque todavía hoy en día no es posible realizar estimaciones precisas del coste y
tiempo que necesitará un proyecto de software.
Englobó a una serie de sucesos que se venían observando en los proyectos de desarrollo de
software:
Los proyectos no terminaban en plazo.
Los proyecto no se ajustaban al presupuesto inicial.
Baja calidad del software generado.
Software que no cumplía las especificaciones.
Código inmantenible que dificultaba la gestión y evolución del proyecto.
Calidad insuficiente del producto final
Estimaciones de duración de proyectos y asignación de recursos inexactas
Retrasos para entregar los productos terminados
Costos de desarrollo y mantención de productos fuera de control
Escasez de personal calificado en un mercado laboral de alta demanda
Tendencia al crecimiento del volumen y complejidad de los productos
Aunque se han propuesto diversas metodologías para intentar subsanar los problemas
mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar
de manera fiable el coste y duración de un proyecto antes de su comienzos.
1.3. Visión genérica de la CONSTRUCCION DEL SOFTWARE
La ingeniería del software surge de la ingeniería de sistemas y de hardware. Abarca un conjunto
de tres elementos claves
- métodos,
- herramientas y procedimientos –
Que facilitan al gestor controlar el proceso del desarrollo del software y suministrar a los que
practiquen dicha ingeniería las bases para constriuir software de alta calidad de una forma
productiva.
Los métodos de la ingeniería del software indican " Cómo" construir técnicamen el software.
Los métodos abarca un amplio espectro de tareas que incluyen:
planificación y estimación de proyectos
análisis de los requisitos del sistema y del software
diseño de estructuras de datos
arquitecturas de programas y procedimientos algorítmicos
prueba y mantenimiento.
Los métodos de la ingeniería de software introducen frecuentemente una notación especial
orientada a un lenguaje o gráfica y un conjunto de criterios para la calidad del software.
Las herramientas de la ingeniería del software suministran un soporte automático o
semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de los
métodos mencionados. Cuando se integran las herramientas de forma que la información creada
por una herraminta pueda ser usada por otra, se establece un sistema para el soporte de
desarrollo del software, llamado ingeniería del software asistida por computadora (en inglés,
CASE) . CASE combina software, hardware y bases de datros sobre la ingeniería del software
(una estructura de datos que contenga la información relevante sobre el análisis , diseño,
codificación y prueba) para crear un entorno de ingeniería del software análogo al
diseño/ingeniería asistido por computadora, CAD/CAE para el hardware.
Los procedimientos de la ingeniería del software son el pegamento que junta los métodos y las
herramientas y facilita un desarrollo racional y oportuno del software de computadora.
Losprocedimientos definen la secuencia en la que se aplican los métodos, las entregas
(documentos, informes, formas, etc) que se requieren, los controles que ayudan a asegurar la
calidad y coordinar los cambios y las directrices que ayudan a los gestores del software a
evaluar el progreso.
La ingeniería del software está compuesta por una serie de pasos que abarcan los métodos, las
herramientas y los procedimiento antes mencionados.Estos pasos se denominan frecuentemente
paradigmans de la ingeniería del software. La elección de un paradigma para la ingeneiría del
software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los
métodos y herramientas a usar y los controles y entregas requeridos. Tres son los paradigmas
que se han tratado ampliamente.
1.4. Definición de la Ingeniería del software
Que es la Ingeniería del Software ?
La Ingeniería del software es una disciplina o área de la Informática o Ciencias de la
Computación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad
que resuelven problemas de todo tipo. Hoy día es cada vez mas frecuente la consideración de la
Ingeniería del Software como una nueva área de la Ingeniería, y el Ingeniero del Software
comienza a ser una profesión implantada en el mundo laboral internacional, con derechos,
deberes y responsabilidades que cumplir, junto a una, ya, reconocida consideración social en el
mundo empresarial y, por suerte, para esas personas con brillante futuro.
La ingeniería del software trata con áreas muy diversas de la Informática y de las Ciencias de la
Computación, tales como construcción de compiladores, sistemas operativos o desarrollos de
Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de
sistemas de información y aplicables a una infinidad de áreas tales como: negocios,
investigación científica, medicina, producción, logística, banca, control de trafico, meteorología,
el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.
Definición del termino Ingeniería del Software
El termino Ingeniería se define en el Diccionario de la Real Academia Española de la Lengua
como: "1. Conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la
utilización de la materia y de las fuentes de energía. 2. Profesión y ejercicio del Ingeniero" y el
termino Ingeniero se define como: persona que profesa o ejerce la Ingeniería. De igual modo la
Real Academia de Ciencias Exactas, Físicas y Naturales de España define el termino Ingeniería
como: " Un conjunto de conocimientos y técnicas cuya aplicación permite la utilización racional
de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras
realizaciones provechosas para el hombre".
Evidentemente, si la Ingeniería del Software es una nueva Ingeniería, parece lógico que reúna
las propiedades citadas en las definiciones anteriores. Sin embargo ni el DRAE(Diccionario de
la Real Academia Española de la Lengua), ni la Real Academia Española de Ciencias han
incluido todavía el termino en sus ultimas ediciones; en consecuencia vamos a recurrir para su
definición mas precisa a algunos de los autores mas acreditados que comenzaron en su
momento a utilizar el termino o bien en las definiciones dadas por organismos internacionales
profesionales de prestigio tales como IEEE o ACM, de los cuales se han seleccionado las
siguientes definiciones de Ingeniería del Software.
Definición 1:
Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y
mantenimiento de sistemas de software [Zelkovits, 1978].
Definición 2:
Ingeniería del Software es la aplicación practica del conocimiento científico en el diseño y
construcción de programas de computadora y la documentación necesaria requerida para
desarrollar, operar(funcionar) y mantenerlos [Bohem, 1976].
Definición 3:
Ingeniería del Software trata del establecimiento de los principios y métodos de la Ingeniería a
fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales [Bauer,
1972].
Definición 4:
La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo,
peración(funcionamiento) y mantenimiento del software; es decir, la aplicación de Ingeniería al
software [IEEE, 1993].
1.5. Metodologías de desarrollo de software
Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y
ayudas a la documentación para el desarrollo de productos software.
Es como un libro de recetas de cocina, en el que se van indicando paso a paso todas las
actividades a realizar para lograr el producto informático deseado, indicando además qué
personas deben participar en el desarrollo de las actividades y qué papel deben de tener.
Además detallan la información que se debe producir como resultado de una actividad y la
información necesaria para comenzarla.
Actualmente es imprescindible considerar los riesgos, aunque habitualmente las empresas, no
han sido concienciadas de los riesgos inherentes al procesamiento de la información mediante
ordenadores, a lo que han contribuido, a veces, los propios responsables de informática, que no
han sabido explicar con la suficiente claridad las consecuencias de una política de seguridad
insuficiente o incluso inexistente. Por otro lado, debido a una cierta deformación profesional en
la aplicación de los criterios de coste/beneficio, el directivo desconocedor de la informática no
acostumbra a autorizar inversiones que no lleven implicito un beneficio demostrable, tangible y
mensurable.
Las técnicas indican cómo debe ser realizada una actividad técnica determinada identificada en
la metodología. Combina el empleo de unos modelos o representaciones gráficas junto con el
empleo de unos procedimientos detallados. Se debe tener en consideración que una técnica
determinada puede ser utilizada en una o más actividades de la metodología de desarrollo de
software. Además se debe tener mucho cuidado cuando se quiere cambiar una técnica por otra.
Una metodología está compuesta por:
Cómo dividir un proyecto en etapas.
Qué tareas se llevan a cabo en cada etapa.
Qué restricciones deben aplicarse.
Qué técnicas y herramientas se emplean.
Cómo se controla y gestiona un proyecto.
Clasificación de las metodologías
Las metodologías se clasifican de la siguiente forma:
Estructuradas.
Orientadas a procesos
Orientadas a datos
Mixtas
No estructuradas.
Orientadas a objetos
Sistemas de tiempo real
Metodologías estructuradas
Se basan en la forma top-down
Metodologías orientadas a procesos
La ingeniería del software se basa en el modelo básico de entrada/proceso/salida de un sistema.
Está compuesta por:
Diagrama de flujo de datos (DFD).
Diccionario de datos.
Especificaciones de proceso.
Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon.
Metodologías orientadas a datos
Son metodologías basadas en la información. Primero se definen las estructuras de datos y, a
partir de éstos, se derivan los componentes procedimentales.
Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr.
Metodologías no estructuradas
Metodologías orientadas a objeto
La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos.
Tiene dos enfoques distintos:
Revolucionario, puro u ortodoxo. Rompen con las metodologías tradicionales.
Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock.
Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman elementos de
uno y otro tipo.
Ejemplos: metodología OMT de Rumbourgh.
Sistemas de tiempo real
Procesan información orientada al control más que a los datos. Se caracterizan por concurrencia,
priorización de procesos, comunicación entre tareas y acceso simultáneo a datos comunes.
2. Sistemas e ingeniería de sistemas (2h)
2.1. Concepto de Sistema
(system). Un sisteam es un conjunto de partes o elementos organizadas y relacionadas que
interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos, energía o
materia del ambiente y proveen (salida) información, energía o materia.
Un sistema puede ser físico o concreto (una computadora, un televisor, un humano) o puede ser
abstracto o conceptual (un software)
Cada sistema existe dentro de otro más grande, por lo tanto un sistema puede estar formado por
subsistemas y partes, y a la vez puede ser parte de un supersistema.
Los sistemas tienen límites o fronteras, que los diferencian del ambiente. Ese límite puede ser
físico (el gabinete de una computadora) o conceptual. Si hay algún intercambio entre el sistema
y el ambiente a través de ese límite, el sistema es abierto, de lo contrario, el sistema es cerrado.
El ambiente es el medio en externo que envuelve física o conceptualmente a un sistema. El
sistema tiene interacción con el ambiente, del cual recibe entradas y al cual se le devuelven
salidas. El ambiente también puede ser una amenaza para el sistema.
Un grupo de elementos no constituye un sistema si no hay una relación e interacción, que de la
idea de un "todo" con un propósito.
En informática existen gran cantidad de sistemas:
• Sistema operativo.
• Sistema experto.
• Sistema informático.
• Aplicación o software.
• Computadora.
2.2. Sistemas de Información (SI)
Un sistema de información (SI) es un conjunto organizado de elementos, estos elementos son
de 4 tipos:
Personas.
Datos.
Actividades o técnicas de trabajo.
Recursos materiales en general (típicamente recursos informáticos y de comunicación,
aunque no tienen por qué ser de este tipo obligatoriamente).
Todo ese conjunto de elementos interactúan entre si para procesar los datos y la información
(incluyendo procesos manuales y automáticos) y distribuirla de la manera más adecuada posible
en una determinada organización en función de sus objetivos. Normalmente el término es usado
de manera errónea como sinónimo de sistema de información informático, estos son el campo
de estudio de la tecnología de la información (IT), y aunque puedan formar parte de un sistema
de información (como recurso material), por sí solos no se pueden considerar como sistemas de
información, este concepto es más amplio que el de sistema de información informático. No
obstante un sistema de información puede estar basado en el uso de computadoras, según la
definición de Langefors1 este tipo de sistemas son:
Un medio implementado tecnológicamente para grabar, almacenar y distribuir expresiones
lingüísticas,
así como para extraer conclusiones a partir de dichas expresiones.
Tipos de sistemas de información
Evolución de los sistemas de información a lo largo del tiempo
Según la función a la que vayan destinados o el tipo de usuario final del mismo, los SI pueden
clasificarse en:
Sistema de procesamiento de transacciones (TPS).- Gestiona la información referente a
las transacciones producidas en una empresa u organización.
Sistemas de información gerencial (MIS).- Orientados a solucionar problemas
empresariales en general.
Sistemas de soporte a decisiones (DSS).- Herramienta para realizar el análisis de las
diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones.
Sistemas de información ejecutiva (EIS).- Herramienta orientada a usuarios de nivel
gerencial, que permite monitorizar el estado de las variables de un área o unidad de la
empresa a partir de información interna y externa a la misma.
Sistemas de automatización de oficinas (OAS).- Aplicaciones destinadas a ayudar al
trabajo diario del administrativo de una empresa u organización.
Sistema experto (SE).- Emulan el comportamiento de un experto en un dominio concreto.
Sistema Planificación de Recursos (ERP).- Integran la información y los procesos de una
organización en un solo sistema.
Estos sistemas de información no surgieron simultáneamente en el mercado; los primeros en
aparecer fueron los TPS, en la década de los 60, y los últimos fueron los SE, que alcanzaron su
auge en los 90 (aunque estos últimos tuvieron una tímida aparición en los 70 que no cuajó, ya
que la tecnología no estaba suficientemente desarrollada).
Otra clasificación, según el entorno de aplicación
Entorno transaccional : Una transacción es un suceso o evento que crea/modifica los datos.
El procesamiento de transacciones consiste en captar, manipular y almacenar los datos, y
también, en la preparación de documentos; en el entorno transaccional, por tanto, lo
importante es qué datos se modifican y cómo, una vez ha terminado la transacción. Los
TPS son los SI típicos que se pueden encontrar en este entorno.
Entorno decisional : Este es el entorno en el que tiene lugar la toma de decisiones; en una
empresa, las decisiones se toman a todos los niveles y en todas las áreas (otra cosa es si esas
decisiones son estructuradas o no), por lo que todos los SI de la organización deben estar
preparados para asistir en esta tarea, aunque típicamente, son los DSS los que encargan de
esta función. Si el único SI de una compañía preparado para ayudar a la toma de decisiones
es el DSS, éste debe estar adaptado a todos los niveles jerárquicos de la empresa.
Aplicación de los sistemas de información
Los sistemas de información tratan el desarrollo, uso y administración de la infraestructura de la
tecnología de la información en una organización.
En la era post-industrial, la era de la información, el enfoque de las compañías ha cambiado de
la orientación hacia el producto a la orientación hacia el conocimiento, en este sentido el
mercado compite hoy en día en términos del proceso y la innovación, en lugar del producto. El
énfasis ha cambiado de la calidad y cantidad de producción hacia el proceso de producción en sí
mismo, y los servicios que acompañan este proceso.
El mayor de los activos de una compañía hoy en día es su información, representada en su
personal, experiencia, conocimiento, innovaciones (patentes, derechos de autor, secreto
comercial). Para poder competir, las organizaciones deben poseer una fuerte infraestructura de
información, en cuyo corazón se sitúa la infraestructura de la tecnología de información. De tal
manera que el sistema de información se centre en estudiar las formas para mejorar el uso de la
tecnología que soporta el flujo de información dentro de la organización.
Áreas de trabajo
El trabajo con los sistemas de información puede centrarse en cualquiera de estas tres áreas
generales:
Estrategia de los sistemas de información.
Gestión de los sistemas de información.
Desarrollo de los sistemas de información.
Cada una de estas ramas se subdivide a su vez en disciplinas que se traslapan con otras ciencias
y con otras disciplinas de la administración tales como ciencias de la computación, ingenierías,
ciencias sociales y ciencias del comportamiento y la administración de negocios.
Estudio de los sistemas de información
Ciborra (2002) define el estudio de los sistemas de información como el estudio que trata la
inserción y el uso de la tecnología de la información en las organizaciones, instituciones, y la
sociedad en general.
2.3. Aplicaciones de las TI a los SI
¿Qué son las Tecnologías de Información (TI’s)?
Hoy en día es muy común escuchar el término TI (Tecnología de información) utilizado por las
empresas, en una manera de representar la búsqueda del desarrollo productivo a través de la
innovación de nuevas herramientas informáticas que fortalezcan y aceleren dicho desarrollo en
pro de la mejora financiera, ayudando al empresario en sus actividades productivas, facilitando
la administración, procesamiento y aprovechamiento de la información, tanto de origen interno
como externo, permitiendo del mismo modo apoyar el área de mercadeo y aprovechar
oportunidades para comerciar en la aldea global.
Enfocándonos a lo anterior, TI podría ser definido entonces como una plataforma de servicios
basada fundamentalmente en la red mundial de Internet y sus componentes de comercio y
negocios electrónicos, así como en la aplicación de software y hardware que soporten las
necesidades de desarrollo de las empresas.
Pero dejando a un lado el enfoque hacía al ámbito empresarial podríamos encontrar una
definición mas globalizada, y decir que la tecnología de información es una forma de denominar
al conjunto de herramientas, habitualmente de naturaleza electrónica, utilizadas para la
recolección, almacenamiento, tratamiento, difusión y transmisión de la información.
Entonces, si desglosamos el término TI, sabemos que Tecnología es la suma total de inventos,
técnicas y conocimientos organizados de los que se disponen para generar algún tipo de
producto o servicio y entendemos por Información a cualquier manifestación, ya sea visual,
auditiva, táctil, de un conjunto de conocimientos.
Es tan grande el cúmulo de información que absorbemos día con día que muchas veces gran
parte de esta pasa desapercibida ante nosotros; porque estamos tan acostumbrados a que mucha
de la información nos llega sin buscarla, no nos percatamos de la gran importancia que tiene
otro tipo información para nuestra vida personal, laboral y cotidiana.
A lo que vamos es que ambos están tan relacionados y su interoperabilidad es tanta que es
aplicada para diversos ámbitos de la vida humana.
Nosotros podríamos decir que vivimos y conocemos ambos términos de nuestra vida cotidiana.
Cada uno de nosotros utiliza la información de maneras muy diversas, desde la persona que
toma un paraguas antes de irse a trabajar, porque vio el estado del tiempo, hasta el inversionista
que compra o vende acciones gracias a la información de la Casa de Bolsa.
Si hablamos también de tecnología podemos hablar desde una persona que enciende el televisor,
el cual cuenta con pantalla plana desarrollada en Japón, para escuchar el noticiero de la noche y
enterarse de lo que acontece en nuestra sociedad y en otros países, hasta otra que enciende su
automóvil que cuenta con un motor alemán, para encender la radio y escuchar las alternativas
del trafico.
De alguna forma u otra siempre buscamos la manera de mantenernos siempre bien informados,
además de buscar la manera de utilizar esa información para nuestro beneficio, y del mismo
modo siempre buscamos la mejor tecnología que satisfaga la mayoría de nuestras necesidades y
mejore nuestra calidad de vida.
Aplicación de Tecnologías de información.
En la actualidad las grandes empresas se enfrentan a un mercado global el cual les obliga a
elevar sus estándares competitivos para convertirse en la mejor de su ramo. Debido a esto, es
que la mayoría de las grandes industrias apuestan hoy en día por el desarrollo y la aplicación de
tecnologías de información, pero cabe mencionar que no es un concepto nuevo, simplemente
por el desconocimiento y el miedo que acarrean los obstáculos más comunes en la
implementación de sistemas de información que son: la resistencia al cambio, definición de
requerimientos, hardware y software, dependencia de los proveedores de tecnología.
Así mismo las pequeñas y Medianas empresas también necesitan incorporar tecnología a sus
estrategias de negocio para poder lograr productividad y eficiencia. Todas estas empresas deben
mantenerse modernizadas; porque manteniéndose así el país estará en la misma situación.
Pero no solo debemos o podemos hablar sobre el sector privado, es muy importante mencionar
que otros sectores tanto como gubernamentales, agrícolas y educativos son algunos otros que
hoy en día afectan a la sociedad directamente y donde las tecnologías deben ser aplicadas con
mayor intensidad y continuidad si queremos que nuestro México deje de ser un país tercer
mundista.
¿Pero como se puede mejorar esto con la aplicación de tecnologías de información? Hace
algunos meses se instalaron en el zócalo de la capital de nuestro país una serie de cámaras, no
pasaron ni veinticuatro horas y ya se había hecho la detención de 2 personas que intentaron
entrar a robar a una farmacia y otra se le encontró culpable por robo a casa-habitación. La
noticia corrió alrededor de los noticieros del país, y nos hicieron pensar que era una medida
preventiva muy viable, sin embargo no pasó ni una semana cuando el gobierno anuncio que no
había capital suficiente para instalar dichas cámaras alrededor de la ciudad. Este mismo tipo de
cámaras redujo la delincuencia en Londres Inglaterra en un 40% entre 1998 y 2003, un número
escandaloso para un periodo de 5 años, y no solo eso además estas mismas cámaras se utilizan
para el servicio de transito, donde junto con un sensor toman la velocidad de los automóviles
que pasan por la avenida, si estos exceden la velocidad la cámara toma una fotografía del auto, y
la envía al departamento de transito quien en su base de datos reconoce al propietario y le envía
por correo su multa a pagar, increíble no? Imagínense como disminuiría esto en México la
corrupción de nuestros agentes de transito?
Otro sector importante, por su esencia en la economía mexicana, es el sector Agrícola el cual
obviamente desconoce este concepto de TI, por la misma negligencia del gobierno en invertir en
esta área como se debiera, por que si miramos hacia la globalización las TI están transformando
rápidamente el sector agrícola en los países desarrollados.
Muchas actividades de mercado son realizadas a través de bases de datos Web especificando
precios, cantidades y calidades demandadas. Las comunicaciones electrónicas y los sitios Web
permiten a los agricultores un acceso más rápido a información sobre crédito, programas de
gobierno y asistencia técnica en distintas modalidades de financiamiento.
Así como en este sector podríamos mencionar aquellos otros que influyen del mismo modo en
la economía de nuestro país, y el cual debemos reconocer que esta atrasado con respecto a las
potencias en este ámbito, ya sea por negligencia, por desconocimiento o falta de capital, pero
áreas tan importantes como la educación quien influye queramos o no en la economía
indirectamente, ya que si la calidad de nuestros profesionistas fuera mayor, mayores serían
nuestros desarrollos y nuestro crecimiento.
Algunos países de años para atrás se ha enfocado más al uso, el desarrollo y la aplicación de las
tecnologías de información tras la entrada de grandes empresas, y el crecimiento de las
transnacionales, así mismo debido al incremento del desempleo y en busca de una mejora en el
nivel de vida de su población, pero estamos lejos y aun falta mucho camino por recorrer, sin
embargo lo mas importante es saber hacia donde vamos y que es lo que se espera de la
aplicación de TI a mayor dimensión en nuestro país.
Por otro lado el desarrollo de tecnologías de información deberá contener todas las habilidades,
procedimientos y técnicas que permitan a las organizaciones manejar eficientemente las
relaciones existentes con los grupos de interés (Clientes, proveedores, gobierno, sindicatos y
público en general) y el entorno en el que se desenvuelven.
2.4. El proceso de la ingeniería de sistemas
Una nueva necesidad y se establezcan los requisitos de un nuevo sistema, habrá cierta actividad
de diseño conceptual, diseño preliminar, etc., hasta llegar al desarrollo de un sistema
completamente configurado, listo para ser utilizado. La realización de las actividades de diseño
conceptual pueden constituir desde la asignación de un reducido
número de personas durante un mes, hasta el empleo de varios expertos en diversas disciplinas
durante períodos de tiempo más prolongados. Esto, por supuesto, variará dependiendo del tipo y
características del sistema, de su complejidad, de la proporción existente entre el desarrollo de
nuevos diseños o la utilización de componentes ya desarrollados, normalizados y disponibles en
el mercado, etc. Sea como fuere, hay un proceso que debe seguirse a partir de la identificación
de una necesidad.
2.1. Requisitos del sistema [9]
Los trabajos de análisis de requisitos, análisis funcional y asignación de requisitos, etc., son
iterativos por naturaleza, yendo de la identificación de una necesidad hasta la definición del
sistema en términos funcionales. Dentro de cada uno de los bloques mostrados, existe un
determinado grado de realimentación.
Por ejemplo, los estudios de soluciones de compromiso se realizan en todos los niveles. Sin
embargo, es imposible representar gráficamente todas las realimentaciones que se pueden
producir. En cualquier caso, el proceso es de arriba-abajo y evolutivo por naturaleza, yendo de
la definición a nivel sistema, al nivel subsistema, y a los principales componentes del sistema.
Su finalidad es describir los requisitos en cada nivel de la jerarquía del sistema, o lo que es lo
mismo, los «QUE» - no los «COMO» - expresados en términos de hardware, software,
instalaciones, personas, datos, etc. específicos. Los recursos que apoyan los «COMO» serán la
consecuencia de desarrollar el análisis y la asignación funcional. Por último, los requisitos
deben ser completos y describir completamente la necesidad del usuario, deben ser objetivos e
incorporables al diseño del sistema, deben ser medibles y demostrables, etc.
2.1.1. Identificación de la necesidad
El proceso de ingeniería de sistemas generalmente comienza con la identificación de una
«apetencia» o «deseo» de uno o más elementos, y se basa en una carencia real (o percibida). Por
ejemplo, determinada capacidad actual no es adecuada en términos de alcanzar ciertos objetivos
de prestaciones, no está disponible cuando se la necesita, no se la puede apoyar adecuadamente,
su utilización es demasiado costosa, etc. O, no se puede establecer el enlace entre los puntos
«A» y «B», transmitir determinado volumen de información con un grado «x» de exactitud, en
un determinado entorno, en cierto período de tiempo, con un grado «y» de fiabilidad, y dentro
de un coste «z» determinado. Como resultado de lo anterior, se define un nuevo requisito para el
sistema en unión de una prioridad para su obtención, de la fecha en que debe estar operativo
para el usuario la nueva capacidad, así como de una estimación de los medios necesarios para su
obtención. La «determinación de la necesidad» debe expresarse en términos cualitativos y
cuantitativos, con el suficiente detalle que justifique el paso a la siguiente fase.
El requisito de identificar la necesidad parece «básico» (evidente). Sin embargo, es muy
corriente encontrarse con que se inician diseños como consecuencia de un interés personal o un
capricho político, sin haberse establecido previamente de forma adecuada sus requisitos. Más
aún, a veces se persiguen desarrollos tecnológicos sin tener una idea concreta de su aplicación
viable. Muchas veces el planteamiento o enunciación del problema resulta ser la parte más
difícil del proceso. Sin embargo, una completa descripción de la verdadera carencia así como de
la necesidad real es muy necesaria, y es importante que los resultados reflejen un requisito del
usuario. Este objetivo puede facilitarse involucrando al consumidor (o «usuario» final) a lo
largo de todo el proceso, desde su iniciación. La aplicación de técnicas, como el «despliegue de
la función de calidad» (Quality Function Deployment, QFD), es apropiada para conseguir el
necesario grado de entendimiento, identificando y asignando prioridades a objetivos concretos,
etc.
2.1.2. Realización de los estudios de viabilidad
Dada la definición de una necesidad es necesario
(1) identificar los diferentes enfoques de diseño a nivel sistema que pueden ser seguidos para
alcanzar los requisitos;
(2) evaluar los candidatos más apropiados en términos de sus prestaciones, efectividad,
requisitos logísticos, y criterios económicos; y
(3) recomendar la línea de acción preferida.
Pueden resultar diversas alternativas; sin embargo, el número de posibilidades debe limitarse a
un número reducido de opciones viables, acordes con los recursos disponibles (como son los de
personal, de material y financieros). Al considerar distintos enfoques de diseño, deben
analizarse las diferentes aplicaciones tecnológicas existentes. Por ejemplo, en el diseño de un
sistema de comunicaciones, ¿se debe usar la fibra óptica o el cable físico convencional? En el
diseño de un avión ¿en qué medida deben usarse materiales compuestos? Cuando se diseña un
automóvil ¿se deben utilizar circuitos integrados de gran rapidez en funciones de control o
debemos inclinarnos por el enfoque electromecánico convencional? Al planificar un proceso
¿en qué medida debemos incorporar recursos informáticos integrados, o emplear la inteligencia
artificial?
Es en esta etapa inicial del ciclo de vida (o sea, en la fase de diseño conceptual) en que las
principales decisiones adoptadas son las que se refieren a un determinado enfoque de diseño, y
es en la que los resultados de dichas decisiones tienen su mayor impacto sobre el coste último
del ciclo de vida del sistema. Las aplicaciones tecnológicas son evaluadas, y en algunos casos
cuando no exista suficiente información, debe iniciarse un proceso de investigación con objeto
de desarrollar nuevos métodos o técnicas para aplicaciones específicas.
Los resultados del análisis de viabilidad repercutirán significativamente no sólo en las
características operativas del sistema sino también en la manufacturabilidad, soportabilidad,
desechabilidad y otras características análogas. La selección (y aplicación) de una tecnología
determinada tiene implicaciones de fiabilidad y mantenibilidad, puede afectar a los requisitos de
fabricación, puede influir de forma determinante en los equipos de prueba y repuestos, y
ciertamente afectará al coste del ciclo de vida del sistema.
De la misma forma, las decisiones relativas a la selección de determi nados procesos, pueden
tener implicaciones en el ciclo de vida. Por ello, es esencial que el ciclo de vida esté siempre
presente en este trabajo de evaluación. El resultado final de esta actividad conduce directamente
al establecimiento de los requisitos operativos del sistema y del concepto de mantenimiento y,
finalmente, se verá reflejado en la especificación del sistema
2.1.3. Definición de los requisitos operativos del sistema
Con el análisis de la necesidad, combinado con la selección del enfoque técnico, es necesario
transformar esta información en términos de requisitos operativos previos. Tales requisitos
deben contemplar los siguientes aspectos:
a. La distribución o despliegue operativo- el número de emplazamientos en los que se
utilizará el sistema, la distribución geográfica y el calendario, así como el tipo y número de
componentes del sistema a situar en cada emplazamiento. Todo ello es la respuesta a la pregunta
- ¿donde se va a utilizar el sistema?
b. Perfil o escenario de la misión - identificación de la misión principal del sistema, y sus
misiones alternativas o secundarias. ¿Qué debe realizar el sistema en respuesta a la necesidad?
Esto puede expresarse a través de una serie de perfiles operativos, que ilustren los aspectos
«dinámicos» necesarios para desarrollar una misión. Son ejemplos, el perfil de vuelo de un
avión entre dos ciudades, la trayectoria a recorrer por un automóvil, y la derrota a seguir por un
barco.
c. Prestaciones y parámetros relacionados- definición de las características operativas o
funciones básicas del sistema. Se refiere a parámetros como alcance o autonomía, precisión,
tasa, capacidad, volumen procesado, potencia de salida, dimensión, y peso. ¿Cuales son los
parámetros críticos de prestación del sistema necesarios para desarrollar su misión en los
diferentes emplazamientos del usuario? Adicionalmente, ¿cómo se relacionan dichos valores
con los perfiles de misión?
d. Requisitos de utilización- uso previsto del sistema, y sus componentes, en el desempeño de
su misión. Se refiere a horas de utilización del equipo por día, tiempo ciclo, ciclos de
utilización-inactividad, porcentaje de capacidad total empleada, carga de instalaciones, etc.
¿Hasta que límite se utilizarán los diferentes componentes del sistema? Esto conduce a calcular
algunas de las solicitaciones impuestas al sistema por el usuario.
e. Requisitos de efectividad- requisitos del sistema, expresados cuantitativamente según sea
aplicable, incluyendo efectividad/ coste del sistema, disponibilidad operativa, seguridad de
misión, tiempo medio entre fallos (Mean Time Between Failures, MTBF), tasa de fallos ("l"),
tasa de alistamiento, tiempo de inactividad por mantenimiento (Maintenance Down Time,
MDT), tiempo medio entre acciones de mantenimiento (Mean Time Between Maintenance,
MTBM), utilización de instalaciones (en tanto por ciento), niveles de cualificación del personal,
costes, y otros similares. Sabiendo que el sistema funcionará ¿qué efectividad o eficiencia se
espera de él?
f. Ciclo de vida operativo (horizonte)- tiempo estimado que se espera esté el sistema en uso
operativo. ¿Cuanto tiempo utilizará el sistema el usuario? ¿Cual es el perfil total de inventario
necesario para el sistema y sus componentes, y donde se situará dicho inventario? Debe
definirse el ciclo de vida del sistema. Aunque el inventario variará según se aumente o reduzca
el ciclo de vida del sistema, es necesario fijar en este punto una «línea de referencia». Sistema
de forma efectiva, por ejemplo: temperatura, vibraciones y choques, ruidos, humedad,
condiciones árticas o tropicales, terreno llano o montañoso, aerotransportado, terrestre y
embarcado. Después un conjunto de perfiles de misión pueden resultar en la especificación de
un rango de valores. ¿A qué estará sujeto el sistema durante su utilización, y por cuánto tiempo?
Además del funcionamiento del sistema, las consideraciones ambientales deben incluir modos
de transporte, manejo y almacenamiento. Es posible que el sistema (y/o alguno de sus
componentes) esté sujeto a un entorno más riguroso durante el transporte que durante su
funcionamiento.
El establecimiento de los requisitos operativos forma la base para el diseño del sistema.
Obviamente, se necesitan respuestas a las siguientes preguntas antes de proseguir:
1. ¿Qué función o funciones desarrollará el sistema?
2. ¿Cuándo será requerido el sistema para realizar su función y durante cuanto tiempo?
3. ¿Dónde se utilizará el sistema?
4. ¿Cómo cumplirá su objetivo el sistema?
La respuesta a estas preguntas debe establecer la línea de referencia. Aunque las condiciones
pueden cambiar, es necesario establecer unos supuestos iníciales. Por ejemplo, los componentes
del sistema serán utilizados de forma distinta en los diferentes emplazamientos de los usuarios,
la distribución de dichos componentes puede variar según varíen las necesidades operativas, y/o
la duración del ciclo de vida puede cambiar como consecuencia de la obsolescencia del sistema
o por criterios competitivos. Aún así, el método descrito anteriormente debe ser realizado para
poder seguir con el diseño del sistema.
2.1.4. Desarrollo de los conceptos de apoyo y mantenimiento
Cuando se analizan los requisitos del sistema, la tendencia normal es comenzar por fijarse en
aquellos elementos del sistema que están relacionados directamente con la «ejecución de la
misión», es decir: equipos principales, personal operador, software operativo, e información
relacionada. Al mismo tiempo se presta poca atención a los conceptos de mantenimiento y
apoyo del sistema. En general, el énfasis en el pasado se centraba sólo sobre parte del sistema, y
no sobre la totalidad del mismo, como se estableció previamente. Para cumplir con los objetivos
generales de la ingeniería de sistemas, es esencial que todos los aspectos del sistema sean
considerados bajo un enfoque integrado desde el principio. Esto incluye no sólo a los elementos
relacionados con la misión principal del sistema, sino también la capacidad de apoyo. Los
principales elementos del sistema deben diseñarse de tal forma que puedan ser apoyados eficaz
y eficientemente durante el ciclo de vida previsto, y la capacidad global de apoyo debe
responder a este requisito. Esto significa que se deben considerar las características del diseño
en lo relativo a la red de apoyo (es decir: repuestos, reparables y consideraciones de inventario),
equipos de apoyo y prueba, equipo de transporte y manejo, recursos informáticos (como el
software), personal y adiestramiento, instalaciones, y datos técnicos. Por tanto, es esencial que
durante la fase del diseño conceptual sea desarrollado un «concepto de apoyo y mantenimiento»
del sistema.
El concepto de mantenimiento se desarrolla partiendo de la definición de los requisitos
operativos del sistema. Constituye una serie de ilustraciones y aseveraciones sobre cómo debe
ser diseñado el sistema para que sea apoyable, mientras que el «plan de mantenimiento » define
los sucesivos requisitos de apoyo del sistema basados en los resultados de los análisis de apoyo
logístico u otros estudios similares El concepto de mantenimiento se plasma finalmente en un
plan de mantenimiento detallado. Refiriéndonos a la figura, se debe tratar el flujo de materiales
y actividades desde el diseño, pasando por la fabricación, hasta los lugares de uso operativo. Se
produce un flujo de mantenimiento cuando los componentes son enviados desde su
emplazamiento operativo a las instalaciones de mantenimiento de segundo o tercer escalón.
Revisando la red en conjunto, se deben considerar aspectos tales como los niveles de
mantenimiento, las responsabilidades y funciones a desarrollar en cada nivel, los criterios de
diseño relativos a los diferentes elementos de apoyo (por ejemplo, tipo de repuestos y niveles de
inventario, fiabilidad de los equipos de prueba, cantidades y cualificaciones del personal), así
como los factores de efectividad de la capacidad global de apoyo. Aunque pueda parecer que el
diseño de los principales componentes de un sistema es el adecuado, la habilidad total del
sistema para cumplir satisfactoriamente su misión depende en gran medida de la estructura y
eficacia del apoyo. Aunque pueden existir variaciones, dependiendo de la naturaleza y tipo de
sistema, el concepto de mantenimiento generalmente incluye la siguiente información:
a. Niveles de mantenimiento - el mantenimiento, preventivo o correctivo, puede realizarse
sobre el mismo sistema (o sobre un elemento del mismo) en su lugar de utilización por el
usuario, en una instalación de segundo escalón, próxima a dicho emplazamiento, o en una
instalación de tercer escalón o del fabricante. Los niveles de mantenimiento conciernen a la
división de funciones y tareas de cada área en la que se ejecute el mantenimiento. La frecuencia
prevista de mantenimiento, la complejidad de las tareas, los requisitos de cualificación del
personal, necesidades de instalaciones especiales, etc, dictan en gran medida las funciones
específicas que deben ser desarrolladas en cada nivel. Dependiendo de la naturaleza y misión
del sistema, pueden establecerse dos, tres y hasta cuatro niveles de mantenimiento. En cualquier
caso, para facilitar las siguientes descripciones clasificaremos el mantenimiento como «de
primer, segundo y tercer escalón».
b. Políticas de reparación - dentro de las limitaciones, puede haber un número de políticas
posibles que especifiquen el grado en que puede realizarse la reparación de un componente del
sistema (caso de que exista). Una política de reparación puede dictar que un elemento sea
designado como no reparable,
parcialmente reparable, o totalmente reparable. Las políticas de reparación se establecen
inicialmente, se desarrollan criterios, y el diseño del sistema progresa enmarcado en la política
de reparación seleccionada. Un ejemplo de una política de reparación para un Sistema XYZ,
desarrollada como parte del concepto de mantenimiento durante la fase del diseño conceptual
c. Responsabilidades orgánicas - la ejecución del mantenimiento puede ser responsabilidad del
usuario, del fabricante (o suministrador), de terceros, o de una combinación de ellos. Además,
estas responsabilidades pueden variar, no sólo con respecto a diferentes componentes del
sistema, sino a medida que se progresa en la fase operativa y de apoyo al sistema. Las
decisiones relativas a responsabilidades orgánicas influirán en el diseño del sistema desde un
punto de vista de diagnóstico y empaquetado, de políticas de reparación, cláusulas de garantía
de los contratos, y otros aspectos afines. Aunque puedan cambiar las condiciones, es necesario
definir en esta fase unos supuestos iníciales.
d. Elementos de apoyo logístico - como parte de la definición del concepto de mantenimiento
inicial, deben establecerse los criterios relativos a los distintos elementos de apoyo logístico.
Estos elementos incluyen el aprovisionamiento (repuestos y reparables, inventarios aso ciados,
datos de aprovisionamiento), equipos de apoyo y prueba, personal y entrenamiento, equipo de
transporte y manejo, instalaciones, datos técnicos y recursos informáticos. Tales criterios, como
datos de entrada al diseño, pueden incluir provisiones de autodiagnóstico, requisitos de prueba
incorporados (built-in) y/o externos, factores de normalización y empaquetado, cantidad y
cualificación de personal, factores y limitaciones de transporte y manejo, etc. El concepto de
mantenimiento proporciona algunos criterios iniciales de diseño del sistema , mientras que la
determinación final de requisitos específicos de apoyo logístico se producirán a través de la
realización del análisis de apoyo logístico (Logistics Support Analysis, LSA), que se realiza
según progresa el diseño. e. Requisitos de efectividad - constituyen los factores de efectividad
asociados a la capacidad de apoyo.
En el área del apoyo logístico, esto puede incluir una tasa de demanda de repuestos, la
probabilidad de que un repuesto esté disponible cuando se necesite, la probabilidad de éxito de
una misión para un determinado número de repuestos, y la cantidad económica de pedido en
relación con la adquisición de inventarios. En lo relativo a los equipos de prueba son factores
determinantes la longitud de la cola de equipos que esperan ser probados, el tiempo de
procesado de la estación de prueba y la fiabilidad del equipo de prueba. En lo que concierne al
transporte son significativos la tasa esperada, sus duraciones, fiabilidad y costes. En cuanto al
personal y su adiestramiento, debe considerarse número y cualificación del personal, niveles de
su formación, tiempo de formación y fiabilidad de los equipos de adiestramiento.
El número de errores por línea de código puede ser una medida importante en el caso del
software. Estos factores deben considerarse en relación con requisitos específicos a nivel
sistema. No tiene sentido especificar unos requisitos muy exigentes para la reparación de
elementos principales de un sistema si se tarda 6 meses en conseguir un repuesto necesario. Los
requisitos de efectividad aplicables a la capacidad de apoyo deben ser un complemento de los de
la totalidad del sistema.
e. Entorno - definición del entorno en lo referente al mantenimiento y apoyo. Esto incluye
temperatura, vibraciones y choques, humedad, ruidos, entornos árticos o tropicales, terrenos
llanos o montañosos, entornos marítimos o terrestres, etc., aplicado a las tareas de
mantenimiento y funciones relacionadas de transporte, manejo y almacenamiento. Resumiendo,
el concepto de mantenimiento constituye la base para el establecimiento de los requisitos de
soportabilidad en el diseño del sistema. Dichos requisitos no solo influyen sobre los elementos
principales del sistema, sino que además deben proporcionar guía en el diseño y/o adquisición
de los elementos necesarios de apoyo logístico. Además, el concepto del mantenimiento
constituye la base para el desarrollo del plan de mantenimiento detallado, que se preparará
durante la fase del diseño detallado y desarrollo.
2.1.5. Desarrollo y asignación de prioridades de medidas de prestaciones técnicas
Tomando como base los requisitos operativos y el concepto de mantenimiento se desarrollan
criterios cualitativos y cuantitativos «para el diseño». Son especialmente interesantes los
factores cuantitativos o métricas asociadas al sistema que se está desarrollando. Estas métricas,
que se suelen denominar «medidas de prestaciones técnicas» (Technical Performance Measures,
TPMs) o «parámetros dependientes del diseño», deben fijarse inicialmente como parte del
proceso de definición de requisitos durante el diseño conceptual. Las TPMs adecuadas deben
identificarse para cada nivel de la estructura jerárquica del sistema e incluirse en la
especificación del sistema (Tipo «A»), deben ser inherentes al subsiguiente proceso de revisión
y evaluación del programa y medirse por medio de la realización de diversos análisis y
predicciones, y deben ser verificadas más tarde a través de la prueba y evaluación del sistema.
Estos factores (o sea, los valores especificados en cada caso) influirán sobre las tecnologías
seleccionadas para el diseño, el empaquetado del sistema y la selección de componentes, las
herramientas/modelos utilizados para los análisis y síntesis del diseño, etc.
En todo sistema, están los factores técnicos, representados aquí como «efectividad del sistema»,
que son una función de sus prestaciones, disponibilidad, fiabilidades de misión, capacidad,
fiabilidad, mantenibilidad, manufacturabilidad, desechabilidad, y otros factores similares que
pueden relacionarse directamente con los requisitos operativos y el concepto del mantenimiento
del sistema. Al otro lado del espectro está el aspecto del coste, que debe ser considerado desde
una perspectiva de ciclo de vida. Aunque existen diversas categorías de costes utilizadas
diariamente en el proceso de toma de decisiones (como costes de obtención o adquisición,
costes de producción y/o construcción, costes operativos y de apoyo, costes de retirada, etc.),
deben ser vistos en el contexto del coste total del ciclo de vida.
Esto es necesario si el aspecto del «riesgo», asociado con las consecuencias de decisiones, va a
ser debidamente considerado. Debe desarrollarse un «árbol de objetivos» (o un enfoque
equivalente), comenzando con un grupo de descriptores generales y continuando con un
desarrollo de arriba-abajo.
Lo que se pretende es partir de un objetivo general del sistema considerado como un todo, y
entonces desarrollar algunos modificadores que apoyen este objetivo del máximo nivel. Esto,
por contra, establece un marco de referencia para la posterior asignación de los criterios de
diseño cualitativos y cuantitativos. Dada la identificación de criterios cuantitativos (es decir,
medidas de prestaciones técnicas), deben establecerse las «prioridades» adecuadas, tal como lo
aprecie el usuario.
Mediante un trabajo en equipo, involucrando al personal adecuado del cliente y del contratista,
las TPMs deben ser priorizadas con el fin de identificar los criterios de diseño que deben
introducirse para cumplir, lo más fielmente posible, las necesidades del usuario. Estos criterios
deben incluirse en las especificaciones adecuadas, empezando por la especificación del sistema
y descendiendo a través de las especificaciones de los diferentes subsistemas, productos,
procesos y/o materiales, que sean necesarias. Los principales factores deben, por supuesto,
recibir la máxima atención de los gerentes y los ingenieros de diseño, y deben ser considerados
en el plan de gestión de riesgos del programa (o equivalente). Nótese que las responsabilidades
de entradas de diseño y de «seguimiento» de estas TPMs a través del proceso de desarrollo del
sistema están alimentadas con diversos componentes de la organización del proyecto.
Ingrediente importante en la realización del proceso de análisis y definición de requisitos, que es
también reiterativo por naturaleza, es la comunicacion necesaria que debe existir entre el
usuario (ej.: el cliente) y el fabricante (ej.: el contratista).
Debe establecerse un trabajo en equipo para realizar una transición efectiva de la especificación
de necesidad del usuario en la definición de los criterios de diseño. El empleo de una técnica
como el despliegue de la función de calidad puede facilitar las necesarias comunicaciones.
2.1.6. Elaboración de la especificación del sistema (Tipo «A»)
Desde la perspectiva de la ingeniería de sistemas, el documento más importante de un
determinado programa, en lo que se refiere al diseño, es la Especificación del Sistema (Tipo
«A»). Incluye los resultados del proceso de análisis de requisitos, y conduce a los requisitos de
diseño de subsistemas y otros componentes del sistema. Básicamente es el «cimiento» a partir
del cual se deriva la totalidad de los requisitos técnicos.
En multitud de proyectos, la especificación del sistema es demasiada vaga y no describe los
requisitos de forma definitiva. Esto se hace a veces intencionadamente para poder introducir
más tarde nuevos requisitos o tecnologías durante el ciclo de vida. Al mismo tiempo se preparan
y negocian contractualmente especificaciones de más bajo nivel (como son las especificaciones
del producto, del proceso, del software, y/o del material), y el diseño detallado de los
subsistemas y componentes progresa sin el beneficio de tener un sólido cimiento sobre el que
construir. Cuando los diferentes componentes son finalmente integrados de abajo-arriba, se
producen desajustes, incompatibilidades, etc.
Esto se convierte generalmente en un proceso costoso. Por ello es fundamental que sea
preparada y seguida fielmente desde el principio una buena y completa especificación del
sistema.
2.2. Análisis funcional y asignación de requisitos
El siguiente paso en el proceso de ingeniería de sistemas es la transformación de los requisitos
del sistema en criterios detallados de diseño y la identificación de los requisitos de recursos
específicos a nivel subsistema e inferior. Esto se realiza mejor por medio del «análisis
funcional». Una función se refiere a una acción concreta o específica que debe desarrollar el
sistema para cumplir un objetivo dado; por ejemplo, la operación que un sistema debe realizar
para cumplir su misión, o la acción de mantenimiento necesaria para devolver el sistema a
condición operativa.
Tales acciones pueden ser realizadas a través de la utilización de equipos, software, personas,
instalaciones, datos, o una combinación de ellos. No obstante, el objetivo en este momento es el
especificar los «QUÉ» y no los «CÓMO»; o sea, qué es necesario realizar en vez de cómo debe
realizarse. No debe identificarse ni adquirirse ningún equipo, elemento de software, elementos
de datos, o elemento de apoyo logístico si no ha sido justificado a través del análisis funcional.
El análisis funcional constituye el proceso iterativo de estructurar o descomponer los requisitos
del nivel sistema, a los subsistemas, y tan abajo en la estructura jerárquica como sea necesario
para identificar los recursos específicos y los distintos componentes del sistema. Representa una
definición del sistema (y actividades asociadas) en términos funcionales e incluye funciones del
sistema, de producción, de utilización, de mantenimiento y apoyo, etc. La realización del
análisis funcional se facilita mediante el uso de diagramas de bloque de flujos funcionales.
Las funciones de alto nivel se descomponen en las de segundo nivel, las funciones operativas
conducen a las de mantenimiento, y se emplea la numeración de bloques para proporcionar
capacidad de seguimiento, tanto descendente como ascendente, de los requisitos. Las funciones
operativas conducen a la descripción de funciones de mantenimiento. Nótese que las
expresiones de cada bloque están «orientadas a acciones », y que los «mecanismos»
básicamente conducen a la identificación de los recursos necesarios para desarrollar la función;
por ejemplo, un equipo, un elemento de software, una herramienta de análisis del diseño, una
instalación, personas, datos de información, u otros cualesquiera.
Esto, por supuesto, debe ser «adaptado a los requisitos específicos de un programa dado» Los
diagramas de bloques funcionales se desarrollan principalmente con objeto de estructurar los
requisitos del sistema en términos funcionales, y sirven para ilustrar la organización del sistema
e identificar las principales interfaces funcionales. El análisis funcional, iniciado durante los
últimos pasos del diseño conceptual, está orientado a permitir la finalización del proceso de
diseño y desarrollo del sistema de una forma completa y lógica. Más concretamente, el enfoque
funcional ayuda a asegurar lo siguiente:
1. Que se han considerado todas las facetas del diseño y desarrollo, producción, utilización, y
apoyo del sistema, es decir, todas las actividades significativas durante el ciclo de vida del
sistema.
2. Que están completamente reconocidos y definidos todos los elementos del sistema, como los
equipos principales, los repuestos y los reparables, el equipo de apoyo y prueba, instalaciones,
el personal, los datos y el software.
3. Que existe un medio para relacionar conceptos de empaquetado y requisitos de apoyo del
sistema con funciones específicas del mismo; o sea, satisfacer los requisitos de buen diseño
funcional.
4. Que se establecen las adecuadas secuencias de relaciones de actividades y diseño, junto con
las interfaces críticas de diseño.
El análisis funcional proporciona una descripción inicial del sistema y, como tal, tiene múltiples
aplicaciones. Por ejemplo, el análisis funcional se utiliza como «entrada» en el desarrollo de los
siguientes requisitos, aplicables a la mayoría de los programas:
1. Diseños eléctricos y mecánicos de empaquetado funcional, seguimiento de funcionamiento y
provisiones de diagnóstico.
2. Modelos de fiabilidad y diagramas de bloques.
3. Análisis de modos de fallos, sus efectos y su criticidad (Failure Modes, Effects, and
Criticality Analysis, FMECA).
4. Análisis de árbol de fallos (Fault Tree Analysis, FTA).
5. Mantenimiento centrado en la fiabilidad (Reliabilitycentered Maintenance, RCM).
6. Análisis de riesgos/seguridad del sistema.
7. Análisis de mantenibilidad.
8. Análisis de nivel de reparación.
9. Análisis de tareas de mantenimiento (Maintenance Task Analysis, MTA).
10. Análisis de tareas de operador (Operator Task Analysis, OTA).
11. Diagramas de secuencia de acciones (Operational Sequence Diagrams, OSDs).
12. Análisis de apoyo logístico (Logistic Support Analysis, LSA).
13. Instrucciones de utilización y mantenimiento.
En el pasado, el análisis funcional, no ha sido siempre realizado en el momento adecuado, si es
que se realizaba. Como conse cuencia de ello, las diferentes disciplinas de diseño asignadas a un
programa determinado han tenido que generar sus propios análisis para cumplir con los
requisitos del mismo. En gran cantidad de casos, estos esfuerzos se realizaban de forma
independiente, y muchas decisiones de diseño se tomaban sin el beneficio de tener una línea de
referencia que seguir. Por supuesto, esto resultaba en discrepancias de diseño y costosas
modificaciones en momentos posteriores del ciclo de vida del sistema. De aquí, el análisis
funcional es necesario y proporciona una excelente línea de referencia y todas las actividades
pertinentes de diseño deben «seguir» la misma fuente de datos (como puede ser la definición de
la configuración del sistema) para satisfacer los objetivos de la ingeniería de sistemas.
Por esta razón, el análisis funcional es considerado una de las actividades fundamentales en el
proceso de ingeniería de sistemas.
Dada una descripción de alto nivel del sistema en términos funcionales, el paso siguiente es
combinar, o agrupar, las funciones similares en subdivisiones lógicas, identificando los
principales subsistemas y componentes de los niveles inferiores de la totalidad del sistema (el
desarrollo de un esquema de empaquetado funcional del sistema). Esto resulta en la
identificación inicial de equipos, software, medios humanos, instalaciones, datos, o sus
combinaciones.
Asignación es «la descomposición de los requisitos a nivel sistema, efectuada de forma
descendente hasta el nivel necesario que proporcione una entrada comprensible para el diseño
y/o la adquisición de un determinado componente del sistema». Como se ve en la figura, es
preciso especificar detalladamente los requisitos de diseños cualitativos y cuantitativos de los
equipos, el software, etc., basados en los requisitos especificados a nivel sistema. Dada una
medida de prestación técnica, tal como el tiempo medio entre acciones de mantenimiento
(MTBM), ¿cuáles deben ser los requisitos de MTBM al nivel de las unidades? Inversamente, los
requisitos de MTBM de las diferentes unidades, cuando sean combinados, deben cumplir los
requisitos de TPM a nivel sistema si éste va a cumplir su misión. Esto es un proceso arriba-
abajo/abajo-arriba, mostrando la «capacidad de seguimiento» de los requisitos hacia abajo y
hacia arriba. En muchos casos en el pasado se ignoró la parte arriba-abajo de este ciclo. En otras
palabras, se había asumido el proceso abajo-arriba, estableciendo primero los requisitos de los
niveles inferiores y esperando que los resultados finalmente respondieran a las necesidades del
usuario. Esto, por supuesto, es un enfoque de «alto-riesgo».
Como último paso, es crítico que las adecuadas TPMs sean incluidas en las diferentes
especificaciones de diseño y/o adquisición de componentes del sistema. Si debe ser desarrollado
un nuevo elemento los requisitos apropiados deben incluirse en la especificación de desarrollo
Tipo «B» (o equivalente); si va a ser adquirido un elemento comercial, los requisitos adecuados
deben en la especificación de producto Tipo «C», y así sucesivamente. Los resultados de la
asignación (y la capacidad de seguimiento de los requisitos) debe ser inherente a las diferentes
especificaciones y normas que se hayan impuesto para un programa determinado.
2.3. Análisis, síntesis, evaluación y optimización del diseño
Con los principales requisitos de diseño establecidos, hay un proceso continuo e iterativo de
análisis, síntesis, evaluación, y optimización del diseño. Este proceso comienza con la
definición en términos generales de una configuración del sistema durante la fase de diseño
conceptual y continua hasta que el sistema y sus componentes estén perfectamente definidos y
listos para entrar en la fase de producción y/o construcción. Parte integrante de este proceso es
la evaluación de alternativas y la realización de estudios de soluciones de compromiso.
Inicialmente pueden considerarse requisitos operativos alternativos y la aplicación de
tecnologías nuevas, o conceptos alternativos de mantenimiento y apoyo. A medida que el diseño
avanza, hay muchas soluciones de compromiso posibles que incluyen aspectos tales como
esquemas alternativos de empaquetado, métodos de diagnostico alternativos,
la evaluación y selección de elementos comerciales, la incorporación de automatismos o la
realización manual de funciones, etc.
Más tarde habrá procesos de fabricación o estructuras de apoyo logístico alternativas que
necesitan ser evaluados. Primero se debe definir el problema, identificar los criterios aplicables
cualitativos y cuantitativos a utilizar en la evaluación (esto es, las medidas de prestaciones
técnicas), seleccionar las técnicas de evaluación adecuadas, seleccionar o desarrollar el modelo
que facilite la evaluación, obtener los datos necesarios de entrada, evaluar cada uno de los
candidatos considerados, realizar un análisis de sensibilidad e identificar áreas potenciales de
riesgo. El modelo seleccionado debe:
(1) representar el mundo real tal y como aplique al problema que trata de resolverse;
(2) representar los aspectos dinámicos de la configuración del sistema que se evalúa;
(3) ser completo por incluir todos los factores relevantes;
(4) ser fiable en términos de repetibilidad de resultados;
(5) ser de estructura lo suficientemente simple como para permitir su oportuna utilización en la
resolución de problemas;
(6) ser diseñado de tal forma que el analista pueda evaluar la configuración aplicable del sistema
como una entidad, analizar diferentes componente del sistema de forma individual, y luego
integrar los resultados en el conjunto; y
(7) ser diseñado para incorporar provisiones de modificación y/o crecimiento para permitir la
evaluación de factores adicionales cuando sea necesario. Un objetivo importante es seleccionar
y/o desarrollar una herramienta que facilite la evaluación de la configuración global del sistema,
así como de las interrelaciones de sus distintos componentes.
Según un reciente estudio, hay más de 350 modelos informáticos disponibles en el mercado, que
desarrollan diferentes funciones . Cada uno de los modelos identificados fue desarrollado de
forma «independiente» o «aislada» en términos de plataformas seleccionadas, lenguajes
informáticos o contextos, requisitos de datos de entrada, grados de «facilidad de manejo», etc.
En general, los modelos identificados no «se hablan entre sí», son complejos y requieren
demasiados datos de entrada, son de difícil manejo y sólo pueden ser utilizados en las últimas
fases del proceso de obtención (es decir, en los últimos momentos del diseño detallado y
desarrollo). Esto no es inesperado, ya que los modelos fueron desarrollados principalmente por
contratistas en respuesta a necesidades percibidas. Al mismo tiempo, muchos diseñadores y
responsables de proyectos buscaban herramientas que pudiesen resolver de forma automática
algunos problemas detallados (contra seleccionar una herramienta que pueda ser utilizada en
muchas situaciones diferentes).
El enfoque abajo-arriba ha sido predominante en la selección de herramientas de diseño. Desde
una perspectiva de ingeniería de sistemas, un buen objetivo es seleccionar y/o desarrollar una
estación de trabajo integrada de diseño, que pueda ser utilizada en todas las fases de la
obtención del sistema y que pueda ser adaptada para considerar los diferentes niveles de
definición del diseño a medida que se progrese desde la fase de definición de requisitos a través
del diseño detallado y desarrollo detallado. Además, debe existir una capacidad por la cual las
herramientas utilizadas en un programa determinado para resolver diferentes problemas se
«hablen entre sí», y puedan conectarse adecuadamente a la estación de trabajo centralizada de
diseño.
Con tal esquema integrado, el ingeniero de sistemas será capaz de realizar más análisis
frontales, investigar pronto muchas más alternativas posibles de diseño, y desarrollar la
configuración preferida en un período de tiempo mucho más corto al tiempo que se reducen los
riesgos «aguas abajo». Finalmente, la selección de las herramientas o modelos informáticos
adecuados debe ser el resultado del análisis funcional y la identificación de las «mejores
prácticas»
El análisis conduce a la síntesis. La síntesis es la combinación y estructuración de los
componentes de tal forma que representen una configuración viable del sistema. Han sido
establecidos los requisitos básicos del sistema, se han realizado algunos estudios de soluciones
de compromiso, y se ha desarrollado una configuración de re ferencia para demostrar los
conceptos anteriormente presentados.
La síntesis es diseño. Inicialmente, la síntesis se utiliza en el desarrollo de conceptos
preliminares y para establecer las relaciones básicas entre los distintos componentes del sistema.
Más tarde, cuando se dispone de la suficiente definición y descomposición funcional, la síntesis
se utiliza para definir aún más los «COMO», en respuesta a los «QUE» del análisis funcional.
La síntesis incluye la selección de una configuración que pueda ser representativa de la forma
que finalmente adoptará el sistema, aunque ciertamente no debe asumirse una configuración
final en este momento.
Dada una configuración resultante de la síntesis, deben evaluarse las características de esta
configuración en términos de los requisitos especificados inicialmente. Se inician los cambios
requerí dos, que conduzcan a la configuración de diseño preferida.
2.4. Integración del diseño
Con relación a la definición de ingeniería de sistemas , uno de los objetivos clave es la necesaria
integración y concurrencia diaria de las distintas actividades del diseño tanto a lo largo como
después del proceso de obtención del sistema. Puede haber muchas disciplinas diferentes de
diseño (representando las diversas áreas de especialidad) requeridas para un programa
determinado. Estas áreas de actividad deben ser adecuadamente integradas en el proceso de
diseño y desarrollo, trabajando «en equipo», de forma efectiva y oportuna.
Hay ciertas áreas de afinidad inherentes a los requisitos para desarrollar las tareas identificadas
en la figura. Por ejemplo, el análisis funcional constituye la base para requisitos de fiabilidad,
mantenibilidad, factores humanos, logística y otros; el análisis de modos de fallos, sus efectos y
criticidad se requiere en la realización de los análisis de fiabilidad, mantenibilidad y apoyo
logístico; se necesita un análisis detallado de tareas para los requisitos del programa de
mantenibilidad, factores humanos y logística; los análisis de coste del ciclo de vida son
inherentes al desarrollo de análisis de requisitos del sistema, viabilidad, fiabilidad,
mantenibilidad, apoyo logístico; etc.
Desde el punto de vista de la ingeniería de sistemas, es esencial que los adecuados elementos
orgánicos que participan en un programa determinado estén íntimamente integrados,
promoviendo las necesarias comunicaciones que deben existir diariamente. Esto puede ser
parcialmente realizado por medio de la co-disposición del personal del proyecto. Si los
miembros de los equipos de proyecto no están situados en la misma zona, es necesario
establecer los adecuados enlaces de comunicaciones mediante la utilización de redes de área
local, métodos de diseño asistidos por ordenador y otros análogos. Por último, debe establecerse
el adecuado entorno orgánico que facilite la consecución de esta necesaria integración. La
organización para la realización y dirección de ingeniería de sistemas.
2.5. Revisión, evaluación y realimentación del diseño
Parte integral del proceso de obtención, es la actividad periódica de revisión y evaluación que
ocurre informalmente de forma diaria, y más formalmente en instantes concretos del ciclo
global de diseño y desarrollo. En relación con esto último, las revisiones formales de diseño
suelen llevarse a efecto después de la finalización del diseño conceptual, las revisiones del
diseño del sistema pueden realizarse durante el diseño preliminar, las revisiones de los
equipos/software pueden realizarse durante el diseño preliminar y detallado, y las revisiones
críticas de diseño puedan realizarse después de que el diseño esté esencialmente «congelado » y
antes de entrar en la fase de producción/construcción. Aunque el tipo y número de revisiones
formales de diseño dependerán de los requisitos específicos de cada programa, servirá como
punto de partida para posteriores discusiones.
En relación con la actividad diaria informal de revisión y evaluación de diseño mostrada en la
figura, ésta incluye el desarrollo inicial de los criterios de diseño, la función diaria de
participación y evaluación del diseño, la revisión y aprobación de documentación de diseño
(dibujos y planos, ilustraciones, listas de material y de repuestos, croquis, informes, etc.) y la
elaboración y procesado de recomendaciones de acciones correctivas y/o de mejoras del
producto.
Dado que esta contínua actividad abarca diferentes disciplinas, es pertinente que sean
identificados (y acordados) desde el principio para que sirvan como «guía para el diseño», los
criterios para éste, las normas sobre equipos y materiales, y los procedimientos relacionados.
Subsiguientemente, deben desarrollarse listas de comprobación para facilitar la revisión y
evaluación de datos/documentación de diseño en términos de los requisitos globales de
especificación del sistema y sus diversos elementos.
El objetivo es:
(1) proporcionar una comprobación metódica del diseño del producto/sistema con respecto a los
requisitos contractuales y de especificaciones;
(2) proporcionar una referencia común a todo el personal del proyecto;
(3) proporcionar un medio para resolver los principales problemas de interface;
(4) proporcionar un registro metódico y sistemático de las decisiones de diseño adoptadas y los
motivos por los que se han tomado; y
(5) promover un diseño más maduro mediante «entradas de grupo». En el proceso se incluye la
revisión de las medidas de prestaciones técnicas y de cómo progresa el diseño en términos de
cumplir con los requisitos.
Puede haber cualquier número de revisiones de diseño programadas de acuerdo con la
complejidad del sistema y el grado de madurez del diseño alcanzado en un momento
determinado. Aunque el objetivo es integrar, coordinar, comunicar, y aprobar de forma
apropiada el diseño a medida que avanza la actividad de desarrollo, la revisión formal de diseño
sirve, en ocasiones, de vehículo de integración y adecuada comunicación. La actividad de
revisión y evaluación del diseño puede ser enormemente beneficiosa, si se realiza de manera
profesional. Sin embargo, una determinada revisión debe ser identificada con la adecuada
documentación de apoyo, el panel de revisión de diseño debe incluir las personas adecuadas que
sean responsables y puedan tomar decisiones sobre la marcha si fuesen necesarias, y las
acciones correctivas necesarias deben iniciarse inmediatamente después de las revisiones (o sea,
la adecuada actividad de seguimiento). Desde la perspectiva de la ingeniería de sistemas, es
esencial la realización de las revisiones formales de diseño.
2.6. Prueba y evaluación del sistema
Paralelamente al establecimiento de los requisitos iniciales del sistema en la fase del diseño
conceptual, debe implantarse un método de medida y evaluación para asegurar la consecución
final de los requisitos especificados. Las medidas de prestaciones técnicas son identificadas y
priorizadas y, al mismo tiempo, debe especificarse cómo será evaluado el sistema en términos
de cumplimiento de esos requisitos de medidas de prestaciones técnicas.
Cuando se considera el tema de la evaluación, el objetivo es conseguir un alto grado de
confianza, lo antes posible en el ciclo de vida, de que el sistema funcionará de la forma deseada.
Esperar a que el sistema haya alcanzado su plena capacidad operativa conducirá a una prueba de
su verdadera capacidad. Sin embargo, si hay problemas y el sistema no cumple con los
requisitos especificados, la incorporación de los necesarios cambios por acción correctiva puede
resultar muy costosa. Por otro lado, si se detectan problemas potenciales en los primeros
momentos del ciclo de vida, cualquier cambio necesario puede incorporarse con un coste
mínimo.
La primera categoría es "analítica", que se refiere a ciertas evaluaciones de diseño que pueden
ser realizadas en las primeras fases de ciclo de vida del sistema utilizando métodos
informatizados entre los que están CAD, CAM, CALS, simulación y otros análogos. "Pruebas
tipo 1" se refiere a la evaluación de los componentes del sistema en el entorno del laboratorio
utilizando modelos, bancos de prueba, etc. Estas pruebas están diseñadas principalmente con el
propósito de verificar ciertas características físicas y de prestaciones y son de desarrollo por
naturaleza. El "prototipado rápido" se emplea en ocasiones con este propósito.
Las "Pruebas tipo 2" incluyen pruebas y demostraciones formales realizadas durante las últimas
etapas de la fase de diseño detallado y desarrollo, cuando están disponibles prototipos pre-
producción de equipos y software. Los prototipos de equipos y software son similares en forma
y función (con partes de componentes operativos incorporados) a los elementos de producción,
excepto que no han sido totalmente aprobados en ese determinado instante. Las "Pruebas tipo 3"
incluyen la terminación de las pruebas formales en emplazamientos designados, realizadas por
el "usuario" durante un cierto período de tiempo. Estas pruebas se realizan normalmente
después de la validación inicial del sistema y antes de completar la fase
producción/construcción. El objetivo es realizar una evaluación técnica completa del sistema.
Las "Pruebas tipo 4", realizadas durante la fase de utilización y apoyo del sistema, incluyen
pruebas formales realizadas en ocasiones con el propósito de obtener información específica
relativa a algún aspecto de la utilización o el apoyo. El objetivo es obtener mayor conocimiento
de la utilización del sistema en el entorno del usuario, o de las operaciones del usuario en
campo. Con relación a la figura, un objetivo de la ingeniería de sistemas es causar la integración
de estos requisitos de prueba de manera rentable. La verificación de algunos componentes
puede realizarse por medios analíticos; otros requisitos pueden cumplirse mediante Pruebas tipo
1, y así sucesivamente. En el plan maestro de prueba y evaluación desarrollado durante la fase
de diseño conceptual debe desarrollarse e incluirse un enfoque integrado total. La
recomendación e iniciación de cambios, como consecuencia de la prueba y evaluación, debe
tratarse de forma individual. Cada cambio propuesto debe ser evaluado, antes de tomar una
decisión respecto a si incorporarlo o no, en términos de su impacto en otros elementos del
sistema y en el coste del ciclo de vida. La viabilidad de incorporar el cambio dependerá de su
extensión, su impacto en el sistema en términos de su habilidad para desarrollar su misión de
signada, y del coste de su implantación.
Si se va a incorporar un cambio, deben implantarse los necesarios procedimientos de control de
cambios. Esto incluye la consideración del momento en que debe realizarse el cambio, los
adecuados elementos serializados afectados de un determinado lote de fabricación, los
requisitos para efectuar cambios en elementos fabricados con anterioridad, el desarrollo y
«prueba» de los conjuntos de modificación de cambios, la localización geográfica donde deben
instalarse los conjuntos de cambios, y los requisitos de comprobación y verificación del sistema
después de haber incorporado el cambio. Es particularmente importante desde la perspectiva de
ingeniería de sistemas el aspecto del control de cambios y el mantenimiento de una
configuración de referencia bien definida. Debe existir una estrecha relación de trabajo entre la
ingeniería de sistemas y la gestión de la configuración.
2.7. Producción y/o construcción
Es necesario definir, al principio de la fase conceptual del diseño y concurrentemente con la
definición de los elementos del sistema que se va a desarrollar, los requisitos de producción (si
van a producirse cantidades múltiples de un elemento) o construcción (de un sistema único en
su clase como una planta de fabricación, un sistema de seguimiento de satélites, un sistema de
distribución de energía, o una red de comunicaciones).
A medida que el diseñador evalúa diferentes opciones técnicas como parte de los análisis de
viabilidad, los requisitos de fabricación, de mecanización, de procedimientos de montaje y
desmontaje, y de enfoque de las pruebas de aceptación del sistema deben ser evaluadas también
en términos de viabilidad. Puede resultar que una determinada tecnología, considerada para su
aplicación en el diseño de los componentes más importantes del sistema, pueda causar
importantes problemas en términos de fabricación y montaje, pruebas, y entorno. No sólo debe
diseñarse para manufacturabilidad (o capacidad de ser construido), sino tenerse en cuenta
también el entorno. ¿Tendrá el proceso de fabricación, debido a los materiales seleccionados en
el diseño, efectos nocivos sobre el entorno? Un objetivo de la ingeniería de sistemas es asegurar
que esta fase de actividad esté adecuadamente integrada desde el comienzo con las otras
características del diseño.
2.8. Utilización y apoyo del sistema
La valoración de las prestaciones y la efectividad de un sistema requiere de la disponibilidad de
los históricos de utilización y de mantenimiento de los diversos elementos del sistema. Las
medidas de prestaciones técnicas se establecen al comienzo del ciclo de vida con el desarrollo
de los requisitos operativos y el concepto de mantenimiento; los requisitos de fiabilidad,
mantenibilidad, factores humanos, soportabilidad, y otros similares se identifican, se realizan
análisis y predicciones a lo largo del desarrollo del sistema; y ahora que el sistema ha sido
desplegado con total capacidad operativa y está siendo utilizado por el usuario, surgen las
siguientes preguntas:
1. ¿Cuales son las verdaderas características de prestaciones y efectividad del sistema?
2. ¿Cual es la verdadera efectividad de su capacidad de apoyo logístico?
3. ¿Se han cubierto los requisitos inicialmente establecidos?
4. ¿Es rentable el sistema desde la perspectiva de su utilización y apoyo?
5. ¿Se están cumpliendo todas las expectativas del usuario?
Dar respuestas a estas preguntas requiere una capacidad formal de información y de
realimentación de datos con las salidas adecuadas en los momentos oportunos. Se debe diseñar,
desarrollar, e implantar un subsistema de datos que cumpla un conjunto específico de objetivos,
que deben estar directamente relacionados con las preguntas anteriores. Más concretamente, el
objetivo es doble:
1. Proporcionar los datos, de forma continua, que se puedan aplicar en la evaluación y
valoración de las prestaciones, efectividad, funcionamiento, mantenimiento, y capacidad de
apoyo logístico del sistema utilizado en campo por el usuario. ¿Se sabe hasta qué punto está
funcionando bien (o mal) el sistema? ¿Se pueden identificar las áreas de debilidad en las que se
puedan realizar mejoras del producto? Aunque estas preguntas puedan parecer «básicas», la
mayor parte de las capacidades de toma de datos y análisis de utilización y mantenimiento
actualmente en uso no proporcionan al ingeniero de sistemas la necesaria visibilidad para una
correcta valoración.
2. Proporcionar una base de datos histórica que cubra sistemas existentes similares en función y
configuración y pueda ser utilizada eficazmente para facilitar el diseño y desarrollo de nuevos
sistemas. Esto se refiere a las «lecciones aprendidas» y a las realimentaciones necesarias para el
desarrollo de la ingeniería al pasar de un programa a otro. Como se transmitió en las Secciones
precedentes de esta monografía, hay multitud de modelos/herramientas disponibles para ayudar
a realizar diferentes análisis. Sin embargo, en la mayoría de los casos, los datos de entrada son
altamente «dudosos » al continuar dependiendo esencialmente de predicciones y estimaciones
basadas en un conocimiento inadecuado del pasado, introduciendo muchas veces un alto grado
de riesgo en el proceso de toma de decisiones. Inherente al proceso de ingeniería de sistemas es
la capacidad continua de evaluación y realimentación. El ingeniero de sistemas debe tener la
necesaria información en términos de «qué está ocurriendo realmente» en el campo, debe ser
capaz de identificar las áreas de debilidad (en términos de ingeniería), y debe ser capaz de
proporcionar recomendaciones de mejoras y/o acciones correctoras.
2.9. Retirada del sistema, desecho del material, rehabilitación y reutilización
Con la preocupación existente actualmente con el medio ambiente, debe prestarse atención no
solo a la obtención y utilización del sistema a lo largo de su pretendido ciclo de vida, sino
también a los requisitos relacionados con la retirada del sistema y el adecuado desecho de sus
componentes. A esta actividad concreta se le ha prestado muy poca (o ninguna) atención en el
pasado; por ello, existen muchos elementos obsoletos que no pueden consumirse, reciclarse, o
dejarse fuera de servicio sin crear un impacto negativo en el entorno, y sus costes de desecho
serán tremendos. Referente al papel de la ingeniería de sistemas, un objetivo clave es el de
«diseñar para desechabilidad» desde el principio; esto es, diseñar un determinado componente
para que pueda ser completamente reciclado cuando se quede obsoleto para desempeñar su
función actual; o diseñar un elemento para que pueda ser desechado por incineración sin
impactar negativamente en el entorno.
Estas características deben considerarse en la realización de los estudios de viabilidad durante la
fase de diseño conceptual, y cuando se definan los requisitos operativos del sistema y su
concepto de mantenimiento. En la toma de decisiones sobre tecnologías, materiales, esquemas
de empaquetado, etc., debe considerarse un enfoque total del ciclo de vida, que incluya las
acciones relacionadas con la retirada del sistema y el desecho del material.
En el caso de que se tenga que tratar con la tarea de retirada de un sistema y desecho del
material obsoleto, cuando las características adecuadas de «diseño para desechabilidad» no
hayan sido incorporadas, es conveniente extender el análisis funcional y realizar un estudio de
soluciones de compromiso que contemple las diferentes opciones para el desecho del material.
Unos enfoques serán menos impactantes que otros, por lo que deberá seleccionarse el que cause
el menor deterioro del entorno.
3. Procesos del software
3.1. Concepto de modelo de proceso
Un conjunto estructurado de actividades cuya meta es el desarrollo o evolución de un software
Algunas actividades genéricas en todos los procesos de software son:
Especificación
Diseño
Desarrollo
Validación
Evolución
Estas actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse
Un proceso es un concepto manejado por el sistema operativo que consiste en el conjunto
formado por:
Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador.
Su estado de ejecución en un momento dado, esto es, los valores de los registros de la
CPU para dicho programa.
Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos.
Otra información que permite al sistema operativo su planificación.
Esta definición varía ligeramente en el caso de sistemas operativos multihilo, donde un proceso
consta de uno o más hilos, la memoria de trabajo (compartida por todos los hilos) y la
información de planificación. Cada hilo consta de instrucciones y estado de ejecución.
Los procesos son creados y destruidos por el sistema operativo, así como también este se debe
hacer cargo de la comunicación entre procesos, pero lo hace a petición de otros procesos. El
mecanismo por el cual un proceso crea otro proceso se denomina bifurcación (fork). Los nuevos
procesos pueden ser independientes y no compartir el espacio de memoria con el proceso que
los ha creado o ser creados en el mismo espacio de memoria.
En los sistemas operativos multihilo es posible crear tanto hilos como procesos. La diferencia
estriba en que un proceso solamente puede crear hilos para sí mismo y en que dichos hilos
comparten toda la memoria reservada para el proceso.
3.2. Modelos de proceso genéricos o de cascada
Es un modelo base para los demás modelos. Fue definido por Royce y se trata principalmente de
que se debe completar un paso correctamente sin ningún error para pasar al siguiente.
Características del modelo cascada
Este modelo muestra de una forma básica el desarrollo de software, y representa en fases
separadas procesos fundamentales.
Dice que se debe probar el software después de construirlo y antes de operarlo. Cada fase tiene
como salida documentación.
Fases del Modelo Cascada
Las fases son:
8 Ingeniería y Análisis del Sistema: establece requisitos de los elementos del sistema.
8 Análisis de los requisitos del software: identifica las funciones del software, el
rendimiento, sus interfaces y la información.
8 Diseño: se basa en estructura de datos, arquitectura del software el detalle de los
procedimientos y la caracterización de la interfaz. Además escoge las herramientas para
la codificación.
8 Codificación: el diseño se traduce en lenguaje de máquina.
8 Pruebas: Aquí se comprueba si existe algún error con el software o si funciona
correctamente. Hasta que sea aceptado por el usuario.
8 Mantenimiento: esta fase se da debido a que después de la entrega pudo haber errores
en el software, o el software no se adapte al entorno externo o que el cliente requiera
ampliaciones funcionales o de rendimiento.
VENTAJA
Este modelo como es sencillo solo utiliza los pasos intuitivos para desarrollar software, además
es fácil de explicarlo al cliente.
DESVENTAJA
8 Los proyectos raramente siguen el flujo secuencial, hay iteraciones
8 El cliente no puede establecer al principio todos los requisitos.
8 El cliente deber tener paciencia pues la versión operativa del producto solo estará
disponible en las últimas etapas del proyecto.
3.3. ITERACIÓN DEL PROCESO
DESARROLLO ITERATIVO Y CRECIENTE (O INCREMENTAL)
Este modelo combina elementos del modelo lineal secuencial con la filosofía interactiva de
construcción de prototipos. Aplica secuencias lineales de la misma forma que progresa el
tiempo en el calendario.
TIEMPO
Entrega 2 incremento
Entrega 3 inc.
Entrega 1 incremento
Diseño
Código
Pruebas
Análisis
Diseño
Código
Pruebas
Análisis
Análisis
Diseño
Código
Pruebas
Características
Usando análisis y mediciones como guías para el proceso de mejora es una diferencia mayor
entre las mejoras iterativas y el desarrollo rápido de aplicaciones, principalmente por dos
razones:
Provee de soporte para determinar la efectividad de los procesos y de la calidad del
producto.
Permite estudiar y después mejorar y ajustar el proceso para el ambiente en particular.
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software,
creado en respuesta a las debilidades del modelo tradicional de cascada.
El modelo de desarrollo incremental provee algunos beneficios significativos para los
proyectos:
Construir un sistema pequeño es siempre menos riesgoso que construir un sistema
grande.
Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, sólo la última iteración necesita ser descartada.
Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del
sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan
cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del
comienzo del próximo incremento.
Ventajas:
Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden
empezar a usarlo desde el primer incremento.
Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las
entregas del sistema.
Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en
cada incremento.
Las partes más importantes del sistema son entregadas primero, por lo cual se realizan
más pruebas en estos módulos y se disminuye el riesgo de fallos.
Desventajas:
Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
Cada incremento debe aumentar la funcionalidad.
Es difícil establecer las correspondencias de los requisitos contra los incrementos.
Es difícil detectar las unidades o servicios genéricos para todo el sistema.
o Debido a la interacción con los usuarios finales, cuando sea necesaria la
retroalimentación hacia el grupo de desarrollo, utilizar este modelo de
desarrollo puede llevar a avances ser extremadamente lento.
o Por la misma razón no es una aplicación ideal para desarrollos en los que de
antemano se sabe que serán grandes en el consumo de recursos y largos en el
tiempo.
o Al requerir constantemente la ayuda de los usuarios finales, se agrega un costo
extra a la compañía, pues mientras estos usuarios evalúan el software dejan de
ser directamente productivos para la compañía.
3.4. El proceso unificado de Rational (RUP)
EL PROCESO RACIONAL UNIFICADO
RUP es un proceso para el desarrollo de un proyecto de un software que define claramente
quien, cómo, cuándo y qué debe hacerse en el proyecto.
Como 3 características esenciales está dirigido por los Casos de Uso: que orientan el proyecto a
la importancia para el usuario y lo que este quiere , está centrado en la arquitectura:
Que Relaciona la toma de decisiones que indican cómo tiene que ser construido el sistema y en
qué orden , y es iterativo e incremental: donde divide el proyecto en miniproyectos donde los
casos de uso y la arquitectura cumplen sus objetivos de manera más depurada Como filosofía
RUP maneja 6 principios clave:
Adatpación del proceso
El proceso deberá adaptarse a las características propias de la organización. El tamaño del
mismo, así como las regulaciones que lo condicionen, influirán en su diseño específico.
Tambien se deberá tener en cuenta el alcance del proyecto.
Balancear prioridades
Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse
recursos limitados.
Debe encontrarse un balance que satisfaga los deseos de todos
.Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una
comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes,
resultados,etc.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas
. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto,
y se refina la dirección del proyecto asi como tambien los riesgos involucrados
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del
software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Éstos se pueden
acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.
Enfocarse en la calidad El control de calidad no debe realizarse al final de cada iteración, sino
en todos los aspectos de la producción
El ciclo de vida de RUP
RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en número
variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas
actividades.
En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades
•Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se identifican los
riesgos. Se define el alcance del proyecto
•Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los
riesgos
•Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y
el manual de usuario
•Transición: se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia
de esto suelen surgir nuevos requisitos a ser analizados.
DESCRIPCIÓN DE LAS ACTIVIDADES
Dependiendo de las iteración del proceso el equipo de desarrollo puede realizar 7 tipos de
actividades en este:
FASE DE INICIO
Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del
negocio y de requisitos.
Modelado del negocio
En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus
procesos.
• Entender la estructura y la dinámica de la organización para la cual el sistema va ser
desarrollado (
• Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
•Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la
organización objetivo.
REQUISITOS
En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios
finales tienen que comprender y aceptar los requisitos que especifiquemos.
•Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema
podría hacer.
• Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
•Definir el ámbito del sistema.
•Proveer una base para estimar costos y tiempo de desarrollo del sistema.
•Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
FASE DE ELABORACIÓN
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la
arquitectura.
ANÁLISIS Y DISEÑO
En esta actividad se especifican los requerimientos y se describen sobre como se van a
implementar en el sistemas
•Transformar los requisitos al diseño del sistema.
•Desarrollar una arquitectura para el sistema.
•Adaptar el diseño para que sea consistente con el entorno de implementación
FASE DE CONSTRUCCIÓN
Implementación
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El
resultado final es un sistema ejecutable.
•Planificar qué subsistemas deben ser implementados y en que orden deben ser integrados,
formando el Plan de Integración.
•Cada implementador decide en que orden implementa los elementos del subsistema.
•Si encuentra errores de diseño, los notifica.
•Se integra el sistema siguiendo el plan.
Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo,
sino que debe ir integrado en todo el ciclo de vida.
•Encontrar y documentar defectos en la calidad del software.
•Generalmente asesora sobre la calidad del software percibida.
•Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por
medio de demostraciones concretas.
•Verificar las funciones del producto de software según lo diseñado.
•Verificar que los requisitos tengan su apropiada implementación. Despliegue
Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo
a los usuarios. Las actividades implicadas incluyen:
•Probar el producto en su entorno de ejecución final.
•Empaquetar el software para su distribución.
•Distribuir el software.
•Instalar el software.
•Proveer asistencia y ayuda a los usuarios.
•Formar a los usuarios y al cuerpo de ventas.
•Migrar el software existente o convertir bases de datos.
DURANTE TODO EL PROYECTO
Gestión del proyecto
Se vigila el cumplimiento de los objetivos, gestión de riesgos y restricciones para desarrollar un
producto que sea acorde a los requisitos de los clientes y los usuarios.
•Proveer un marco de trabajo para la gestión de proyectos de software intensivos.
•Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el
proyecto.
• Proveer un marco de trabajo para gestionar riesgos.
Configuración y control de cambios
El control de cambios permite mantener la integridad de todos los artefactos que se crean en el
proceso, así como de mantener información del proceso evolutivo que han seguido.
Entorno
La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas,
procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar en
cada momento, así como definir la instancia concreta del proceso que se va a seguir. En
concreto las responsabilidades de este flujo de trabajo incluyen:
•Selección y adquisición de herramientas
•Establecer y configurar las herramientas para que se ajusten a la organización.
•Configuración del proceso.
•Mejora del proceso.
•Servicios técnicos. ROLES EN RUP
Analistas:
•Analista de procesos de negocio.
•Diseñador del negocio.
•Analista de sistema.
•Especificador de requisitos. Desarrolladores:
•Arquitecto de software.
•Diseñador
•Diseñador de interfaz de usuario
•Diseñador de cápsulas.
•Diseñador de base de datos.
•Implementador.
•Integrador. Gestores:
•Jefe de proyecto
•Jefe de control de cambios.
•Jefe de configuración.
•Jefe de pruebas
•Jefe de despliegue
•Ingeniero de procesos
•Revisor de gestión del proyecto
•Gestor de pruebas. Apoyo:
•Documentador técnico
•Administrador de sistema
•Especialista en herramientas
•Desarrollador de cursos
•Artista gráfico Especialista en pruebas:
•Especialista en Pruebas (tester)
•Analista de pruebas
•Diseñador de pruebas
Otros roles:
•Stakeholders
• Revisor
•Coordinación de revisiones
•Revisor técnico
•Cualquier rol Notas:
•Para grandes organizaciones con un números equipos de ingenieros y la comunicación entre
cada equipo es crítica por lo tanto es necesario que los artefactos sean completos y bastante
comprensivos
•En tanto que para pequeños proyectos no es recomendable presentarse tanto rigor en las
preparaciones de los artefactos, la eficiencia del proceso depende más de las habilidades de cada
trabajador
4. REQUISITOS DEL SOFTWARE (5H)
4.1. Qué son los requisitos y Clasificación de los 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. 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 clasificado en 5 pasos distintos:
1. Identificación de Requisitos.2. Análisis de Requisitos y Negociación.3. Especificación de Requisitos. 4. Modelizado 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 sistema o producto va a ser utilizado en el día a día-. Esto que parece simple, es muy complicado. Christel y Kang [CRI92] 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 [SOM97] 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 ambiguos como candidatos para el prototipado, 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?
Es corriente en clientes y usuarios solicitar más de El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de 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» [SOM97] 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.
La Especificación del Sistema es el producto final sobre los requisitos del sistema obtenido por el ingeniero. Sirve como fundamento para la ingeniería del hardware, ingeniería del software, la ingeniería de bases de datos y la ingeniería humana. Describe la función y características de un sistema de computación y las restricciones que gobiernan su desarrollo. La especificación delimita cada elemento del sistema. La especificación del sistema describe la información (datos y control) que entra y sale del sistema
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 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 erroresdetectados 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 sistema5 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, norma, documento)? ¿El
planteamiento final del requisito ha sido contqastado 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?
Las preguntas planteadas en la lista de comprobación ayudan a asegurar que el equipo de validación dispone de lo necesario para realizar una revisión completa de cada requisito.
4.2. El proceso de la Ingeniería de requisitos.
Es muy importante definir cuál es el proceso de ingeniería de requisitos ya que esto nos va a
servir para la obtención correcta de los requerimientos. Se han definido diversos modelos a
nivel de toda la Ingeniería de Software, así tenemos para el desarrollo de aplicaciones web, de
escritorio, o sencillamente se ha definido un estándar, pero en general, la mayor parte de estos
procesos tienen un símil y lo único que buscan es recopilar la mayor cantidad de requerimientos
correctos para así conformar una buena estructura que servirá de base para el desarrollo de un
proyecto.
En la figura, se muestra un esquema del proceso de la ingeniería de requisitos basado en la
Ingeniería de Software de Gestión. El proceso se cumple en cinco fases: viabilidad, captura y
análisis, especificación, validación y gestión de requisitos.
Estudio de viabilidad: Este permitirá rendir un informe tanto al equipo de desarrollo del
proyecto como al usuario o cliente, donde se verificará si el proyecto vale la pena desarrollarlo.
Es de vital importancia para la satisfacción de los objetivos del negocio.
Captura y Análisis: En esta fase el desarrollador o su equipo de desarrollo entran en contacto
con el usuario final o con el cliente para determinar el alcance del proyecto o del sistema que se
desea construir, además, se debe identificar cuáles son los servicios que prestará el sistema, su
rendimiento, sus necesidades y restricciones, y cuáles son los objetivos esperados.
Especificación: Aquí se debe obtener un documento de especificación de requisitos, en cual se
llega a definir de una forma completa, precisa y verificable cada uno de los requerimientos o
necesidades que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones
(software, hardware).
Validación: Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos definen
el sistema o proyecto que se va a construir y que desea el cliente. En esta etapa solamente entran
aquellos requisitos que se mencionaron ya en la especificación.
Gestión: Se realiza la comprensión y control de los cambios de cada una de los requisitos, sean
estos requisitos estables (corresponden al estado del sistema) o volátiles (representan eventos
que hacen que el sistema realice una función dada).
4.3. Modelo de Casos de Uso
Concepto de Caso de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un
actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica.
Expresa una unidad coherente de funcionalidad del sistema.
El caso de uso refleja una tarea específica que el actor desea llevar a cabo usando el sistema.
1. ELEMENTOS DE UN DIAGRAMA DE CASOS DE USO
Un diagrama de caso de uso muestra la relación entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interacción externa.
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: Actores, Casos
de uso y relaciones entre casos de uso.
1.1. Actores
Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el
mismo. Se representa mediante una figura humana dibujada con palotes. Esta
representación sirve tanto para actores que son personas como para otro tipo de
actores (otros sistemas, sensores, etc.).
1.2. Casos de uso
Un caso de uso se representa en el diagrama mediante una elipse con el nombre del
caso de uso en su interior.
El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a
cabo usando el sistema.
A los casos de uso no sólo se los representa en diagramas, la verdadera utilidad es
expresarlos en un documento narrativo que describe la secuencia de eventos de un
actor (un agente externo) que usa un sistema para completar un proceso [Jacobson].
Es una historia o una forma particular de usar un sistema. Los casos de uso no son
exactamente requisitos ni especificaciones funcionales, pero ilustran e implican
requisitos en las historias que cuentan.
1.3. Relaciones entre Casos de Uso
Entre dos casos de uso puede haber las sigtes relaciones.
Extiende: Cuando un caso de uso especializa a otro extendiendo su
Funcionalidad.
Usa: Cuando un caso de uso utiliza a otro.
Se representan como una línea con los dos casos de uso relacionados, con una flecha
en forma de triangulo y con una etiqueta <<Extiende>> o <<usa>> según sea el tipo
de relación.
En el diagrama de casos de uso se representa el sistema como una caja rectangular
con el nombre en su interior. Los casos de uso en el interior de la caja del sistema, y
los actores fuera, y cada actor está unido a los casos de uso en los que participa
mediante una línea.
5. Análisis. Modelado del software (8h)
5.1. Modelos de contexto
5.2. Modelos de comportamiento
El modelado del comportamiento es uno de los priniipios fundamentales de todos los métodos de análisis de requisitos. Sin embargo, sólo algunas versiones ampliadas del análisis estructurado ([WAR85], [HAT87]) proporcionan una notación para este tipo de modelado. El diagrama de transición de estados representa el comportamiento 'de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado. Además, el DTE indica qué acciones (por ejemplo, activación de procesos) se llevan a cabo como consecuencia de un suceso determinado.
Un estado es un modo observable de comportamiento.Por ejemplo, estados para un sistema de supervisión y de control para que las válvulas de presión. puedan estar en: estado de supervisión, estado de alarma, estado de liberación depresión y otros. Cada uno de estos estados representa un modo de comportamiento del sistema. Un diagrama de transición de estados indica cómo se mueve el sistema de un estado a otro.
Para ilustrar el uso de las ampliaciones de comportamiento y de control de Hatley y Pirbhai, consideremos el software empotrado en una máquina fotocopiadora de oficina. En la Figura 1 se muestra un flujo de control para el software de fotocopiadora. Las flechas del flujo de datos se han sombreado ligeramente con propósitos ilustrativos, pero en realidad se muestran como parte de un diagrama de flujo de control.
Los flujos de control se muestran de cada proceso individual y las barras verticales representan las «ventanas » EC. Por ejemplo, los sucesos estado de alimentación del papel y de comienzo/parada fluyen dentro de la barra de EC. Esto implica que cada uno de estos sucesos hará que se active algún proceso representado en el DFC. Si se fueran a examinar las interioridades del EC, se mostraría el suceso comien-zo/parada para activar/desactivar el proceso de gestión de
copiado. De forma similar, el suceso atascada (parte del estado de alimentación del papel) activaría realizar diagnóstico del problema. Se debería destacar que todas las barras verticales dentro del DFC se refieren a la misma EC. Un flujo de suceso se puede introducir directamente en el proceso como muestra fallo de reproducción. Sin embargo, este flujo no activa el proceso, sino que proporciona información de control para el algoritmo de proceso.
Un diagrama de transición de estados simplificado para el software de fotocopiadora descrito anteriormente se muestra en la Figura 2. Los rectángulos representan estados del sistema y las flechas representan transiciones entre estados. Cada flecha está etiquetada con una expresión en forma de fracción. La parte superior indica el suceso (o sucesos) que hace(n) que se produzca la transición. La parte inferior indica la acción que se produce como consecuencia del suceso. Así, cuando la bandeja de papel está llena, y el botón de comienzo ha sido pulsado, el sistema pasa del estado leyendo órdenes al estado realizando copias. Observe que los estados no se corresponden necesariamente con los procesos de forma biunívoca. Por ejemplo, el estado realizando copias englobaría tanto el proceso gestión de copiado como el proceso producir visualización de usuario que aparecen en la Figura 1.
5.3. Modelos de datos
El modelado de datos responde a una serie de pregun- ,tas específicas importantes para cualquier aplicación de procesamiento de datos. ¿Cuáles son los objetos de datos primarios que va a procesar el sistema? ¿Cuál es la composición de cada objeto de datos y qué atributos describe el objeto? ¿Dónde residen actualmente los objetos? ¿Cuál es la relación entre los objetos y los procesos que los transforman?
Para responder estas preguntas, los métodos de modelado de datos hacen uso del diagrama de entidad-relación (DER). El DER, descrito con detalle posteriormente en esta sección, permite que un ingeniero del software identifique objetos de datos y sus relaciones mediante una notación gráfica. En el contexto del análisis estructurado, el DER define todos los datos que se introducen, se almacenan, se transforman y se producen dentro de una aplicación.
El diagrama entidad-relación se centra solo en los datos (y por consiguiente satisface el primer principio operacional de análisis), representando una «red de datos» que existe para un sistema dado. El DER es específicamente Útil para aplicaciones en donde los datos y las relaciones que gobiernan los datos son complejos, el modelado de datos estudia los datos independientemente del procesamiento que los transforma.
1. Objetos de datos, atributos y relaciones
El modelo de datos se compone de tres piezas de información interrelacionadas: el objeto de datos, los atributos que describen el objeto de datos y la relación que conecta objetos de datos entre sí.
Objetos de datos. Un objeto de datos es una representación de cualquier composición de información compuesta que deba comprender el software. Por composición de información, entendemos todo aquello que tiene un número de propiedades o atributos diferentes. Por tanto, el «ancho» (un valor sencillo) no sería un objeto de datos válido, pero las «dimensiones» (incorporando altura, ancho y profundidad) se podría definir como objeto.
Un objeto de datos puede ser una entidad externa (por ejemplo, cualquier cosa que produce o consume información), una cosa (por ejemplo, un informe o una pantalla), una ocurrencia (por ejemplo, una llamada telefónica) o suceso (por ejemplo, una alarma), un puesto (por ejemplo, un vendedor), una unidad de la organización (por ejemplo, departamento de contabilidad), o una estructura (por ejemplo, un archivo
Atributos. Los atributos definen las propiedades de un objeto de datos y toman una de las tres características diferentes. Se pueden usar para (1) nombrar una ocurrencia del objeto de datos, (2) describir la ocurrencia, o ( 3 ) hacer referencias a otra ocurrencia en otra tabla. Además, uno o varios atributos se definen como un identifcador -es decir, el atributo identificador supone una «clave» cuando queramos encontrar una instancia del objeto de dato-. En algunos casos, los valores para los identificadores son únicos, aunque esto no es un requisito. Haciendo referencia al objeto de datos coche, un identificador razonable podría ser el número de bastidor.
El conjunto de atributos apropiado para un objeto de datos dado se determina mediante el entendimiento del contexto del problema. Los atributos para coche descritos anteriormente podrían servir para una aplicación que usara un Departamento de Vehículos de Motor, pero estos atributos serían menos útiles para una compañía de automóviles que necesite fabricar software de control.
En este último caso, los atributos de coche podrían incluir también número de bastidor, tipo de carrocería, y color, pero muchos atributos adicibnales (Por ejemplo: código interior, tipo de dirección, selector de equipamiento interior, tipo de transmisión) se tendrían que añadir para que coche sea un objeto significativo en el contexto del control de fabricación.
Relaciones. Los objetos de datos se conectan entre sí de muchas formas diferentes. Considere dos objetos de datos, libro y librería.. Se establece una conexión entre libro y librería porque los dos objetos se relacionan. Pero, ¿qué son relaciones? Para determinar la respuesta, debemos comprenderel papel de libro y librería dentro del contexto del software que se va construir. Podemos definir unconjunto de parejas objeto-relación que definen las relaciones relevantes. Por ejemplo,una librería pide librosuna librería muestra librosuna librería almacena librosuna librería vende librosuna librería devuelve libros
Cardinalidad y modalidad
Los elementos básicos del modelado de datos –objetos de datos, atributos, y relaciones- proporcionan la base del entendimiento del dominio de información de un problema. Sin embargo, también se debe comprender la información adicional relacionada con estos elementos básicos.
Hemos definido un conjunto de objetos y representado las parejas objeto-relación que los limitan. Una simple referencia: el objeto X que se relaciona con el objeto Y no proporciona información suficiente para propósitos de ingeniería del software. Debemos comprender la cantidad de ocurrencias del objeto X que están relacionadas con ocurrencias del objeto Y. Esto nos conduce al concepto del modelado de datos llamado cardinalidad.
Cardinalidad. El modelo de datos debe ser capaz de representar el número de ocurrencias de objetos que se dan en una relación. Tillman [TIL93] define la cardinulidad de una pareja objeto-relación de la forma siguiente:
La cardinalidad es la especificación del número de ocurrencias [de un objeto] que se relaciona con ocurrencias de otro [objeto]. La cardinalidad normalmente se expresa simplemente como «uno» o «muchos». Por ejemplo, un marido puede tener solo una esposa (en la mayoría de las culturas), mientras que un padre puede tener muchos hijos. Teniendo en consideración todas las combinaciones de «uno» y «muchos», dos [objetos] se pueden relacionar como:
Uno a uno (1 : l)--Una ocurrencia [de un objeto] «A» se puede relacionar a una y sólo una ocurrencia del objeto «B», y una ocurrencia de «B» se puede relacionar sólo con una ocurrencia de «A».
Uno a muchos (1:N)-Una ocurrencia del objeto «A» se puede relacionar a una o muchas ocurrencias del objeto «B», pero una de «B» se puede relacionar sólo a una ocurrencia de «A». Por ejemplo, una madre puede tener muchos hijos, pero un hijo sólo puede tener una madre.
Muchos a muchos (M:N)-Una ocurrencia del objeto «A» puede relacionarse con una o más ocurrencias de «B», mientras que una de «B» se puede relacionar con una o más de «A». Por ejemplo, un tío puede tener muchos sobrinos, mientras que un sobrino puede tener muchos tíos.
La cardinalidad define «el número máximo de relaciones de objetos que pueden participar en una relación» [TIL93]. Sin embargo, no proporciona una indicación de si un objeto de datos en particular debe o no participar en la relación. Para especificar esta información, el modelo de datos añade modalidad a la pareja objeto-relación.
Modalidad. La modalidad de una relación es cero si no hay una necesidad explícita de que ocurra una relación, o que sea opcional. La modalidad es 1 si una ocurrencia de la relación es obligatoria. Para ilustrarlo, consideremos el software que utiliza una compañía telefónica local para procesar peticiones de reparación. Un cliente indica que hay un problema. Si se diagnostica que un problema es relativamente simple, sólo ocurre una única acción de reparación. Sin embargo, &el problema es complejo, se pueden requerir múltiples acciones de reparación.
Diagramas Entidad-Relación
La pareja objeto-relación es la piedra angular del modelo de datos. Estas parejas se pueden representar gráficamente mediante el diagrama entidad relación (DER). El DER fue propuesto originalmente por Peter Chen [CHE77] para el diseño de sistemas de bases de datos relacionales y ha sido ampliado por otros. Se identifica un conjunto de componentes primarios para el DER: objetos de datos, atributos, relaciones y varios indicadores tipo. El propósito primario del DER es representar objetos de datos y sus relaciones.
Una notación DER rudimentaria. Los objetos de datos son representados por un rectángulo etiquetado. Las relaciones se indican mediante una línea etiquetada conectando objetos. En algunas variaciones del DER, la línea de conexión contiene un rombo que se etiqueta con la relación. Las conexiones entre objetos de datos y relaciones se establecen mediante una variedad de símbolos especiales que indican cardinalidad y modalidad.
5.4. Análisis de software orientado a objetos
6. Diseño del software (6h)
6.1. Principios y conceptos fundamentales del diseño
6.2. Diseño arquitectónico
6.3. Arquitecturas de sistemas distribuidos
6.4. Arquitecturas de aplicaciones
6.5. Diseño orientado a objetos
7. Verificación y validación. (2h)
7.1. Conceptos básicos
7.2. Pruebas del software
