INDICE

INTRODUCCIÓN...............................................................................................................2CAPITULO 1. INGENIERÍA DEL SOFTWARE.......................................................................31. El Software y el Proceso..........................................................................................3

1.1 Características del software..........................................................................................31.2 Componentes del software............................................................................................41.3 Aplicaciones del software.............................................................................................51.4 Ingeniería del Software.................................................................................................61.5 Sistemas Basados en Computadora...............................................................................91.6 Ingeniería de la información.......................................................................................111.7 Ingeniería de productos...............................................................................................11

2. Gestión de proyectos de software.............................................................................112.1 Planificación de proyectos..........................................................................................132.2 Actividades asociadas a la planificación de proyectos de software............................142.3 Estimación del proyecto de software..........................................................................152.4 Modelos empíricos de estimación...............................................................................162.5 Herramientas automáticas de estimación....................................................................17

3. Análisis de sistemas..................................................................................................173.1 Identificación de las necesidades (análisis de requisitos)...........................................183.2 Estudio de la viabilidad...............................................................................................213.3 Análisis técnico y económico.....................................................................................223.4 Modelado de la arquitectura del sistema.....................................................................233.5 Especificación del sistema..........................................................................................233.6 Creación de prototipos del software...........................................................................24

1.4 Diseño de sistemas.................................................................................................251.4.1 Diseño de datos........................................................................................................251.4.2 Diseño arquitectónico..............................................................................................261.4.3 Diseño de la interfaz................................................................................................274.4 Diseño procedimental.................................................................................................271.4.4 Arquitectura del software.........................................................................................281.4.6 Criterios para evaluar la calidad del diseño.............................................................28

1.5 Desarrollo de software...........................................................................................291.6 Prueba del software..............................................................................................29

1.6.1 Objetivos de la prueba..............................................................................................301.6.2 Verificación y validación.........................................................................................30

1.7 Implantación...........................................................................................................301.7.1 Capacitación de usuarios del sistema.......................................................................301.7.2 Evaluación del sistema.............................................................................................31

1.8 Mantenimiento.......................................................................................................311.9 Calidad del Software...............................................................................................32

1.9.1 Factores de calidad del software..............................................................................331.10.2 Bibliografía............................................................................................................345.2 Bibliografía.................................................................................................................34

INTRODUCCIÓN

Las técnicas de modelación de objetos constituyen una nueva forma de pensar acerca de los problemas, empleando diversos modelos que se organizan a partir del mundo real. Los modelos orientados a objetos son útiles para comprender los problemas, comunicarse con los expertos de la aplicación, modelar la empresa, documentar y diseñar programas y bases de datos.

La esencia del desarrollo orientado a objetos es la identificación y organización de conceptos del dominio de la aplicación y no de su representación final en un lenguaje de programación. El desarrollo orientado a objetos es un proceso conceptual, es una forma de pensar y no una técnica de programación. . Sus beneficios mayores proceden de la ayuda que ofrecen a quienes construyen las especificaciones, a los desarrolladores y a los clientes para que expresen conceptos abstractos y se comuniquen unos con otros.

El Lenguaje Unificado de Modelado (UML Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. Proporciona una forma estándar de describir los planos del sistema, cubriendo las cosas conceptuales tales como: procesos de negocio y funciones del sistema, así como las cosas concretas tales como: clases escritas en un lenguaje de programación, esquemas de bases de datos y componentes reutilizables.

La metodología de análisis y diseño orientados a objetos OMT es un proceso para la producción organizada de software orientado a objetos, consta de una serie de etapas o pasos a seguir que se organizan dentro de un ciclo de vida con varias fases de desarrollo, y que van desde la formulación inicial del problema, pasando por el análisis, diseño, implementación y prueba del software, y una fase adicional de mantenimiento si es necesaria. Está basada en el uso de una notación orientada a objetos para describir clases y relaciones a lo largo de todo el ciclo vital.

En el presente material se expone en su primera parte un resumen de la Ingeniería del Software, pasando por las diferentes etapas del ciclo de vida del desarrollo de un software. En su segunda parte se presenta el lenguaje de representación gráfica UML, de manera que usted pueda dominar el vocabulario, reglas y especificaciones del lenguaje, así como usarlo para resolver problemas. En su tercera parte se presenta un resumen de la metodología OMT de análisis y diseño orientados a objetos, con el objetivo de que se conozcan los distintos pasos a seguir en la creación de software. .

2

CAPITULO 1. INGENIERÍA DEL SOFTWARE

1. El Software y el Proceso.

¿Qué es realmente el software? El software es un producto que permite la utilización de la potencia del hardware informático en su mayor medida, produciendo y gestionando información, mostrándola y modificándola. Es la base de control de la computadora (sistemas operativos), la comunicación de información (redes), y hasta de la creación y control de otros softwares (herramientas de desarrollo y entornos). Entrega información (considerada por muchos el producto más importante) y proporciona el medio de adquirirla, gestiona información comercial en vistas a mejorar la competitividad, permite el acceso a las redes de comunicación (Internet). Su papel ha cambiado mucho desde las décadas anteriores a la actualidad, provocado esto por las grandes mejoras en el hardware y los cambios en las arquitecturas informáticas, como son el aumento de la capacidad de memoria y de almacenamiento.

Sin embargo, persisten y aumentan un conjunto de problemas relacionados con el software. Entre ellos tenemos que los avances del hardware dejan atrás la capacidad de producir software para alcanzar el potencial del mismo, la demanda de nuevos programas es más grande que la capacidad de producción de software y por tanto no se cubren las necesidades del mercado y los negocios, la sociedad es cada vez más dependiente de la fiabilidad del software y sus fallos provocan daños económicos y a veces humanos grandes, por lo cual se lucha por un software de alta calidad y fiabilidad.

El software puede considerarse como:1. instrucciones (programas de computadoras) 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, y3. documentos que describen la operación y el uso de programas.

1.1 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. Cuando se construye hardware, el proceso creativo humano se traduce finalmente en una forma física. El software es un elemento del sistema que es lógico, en lugar de físico, por tanto el software tiene características considerablemente distintas a las del hardware:

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 diferentes, en ellas la buena calidad se adquiere mediante un buen

3

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 y requieren de métodos de construcción del producto final, pero la relación entre las personas dedicadas y el trabajo realizado es completamente diferente para el software, así como los métodos utilizados.

El software no se «estropea». Los fallos iniciales en el hardware una vez corregidos hacen que la tasa de fallos baje a un nivel donde permanece hasta un período de tiempo en que los componentes de hardware sufren los efectos acumulativos de la suciedad, la vibración, los malos tratos, las temperaturas extremas y muchos otros males externos. Sencillamente, el hardware comienza a estropearse. El software no es susceptible a los males del entorno que hacen que el hardware se estropee. Los defectos no detectados harán que falle el programa durante las primeras etapas de su vida pero estos se corrigen.

La implicación es clara, el software no se estropea, pero se deteriora, pues sufre cambios (mantenimientos) en su vida y conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos, haciendo que se solicite otro cambio. Lentamente, el nivel mínimo de fallos comienza a crecer; el software se va deteriorando debido a los cambios. 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 máquina ejecutable. Por tanto, el mantenimiento en el software es más complejo que en el hardware, pues para este último se cuenta con piezas de repuesto, lo cual no es así en el caso del software.

La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. Para el diseño y construcción de hardware de control para un producto basado en un microprocesador el ingeniero construye un esquema de la circuitería digital, hace algún análisis fundamental para asegurar que se realiza la función adecuada y va al catálogo de ventas de componentes digitales existentes, donde cada circuito integrado tiene un número de pieza, una función definida y válida, una interfaz bien definida y un conjunto estándar de criterios de integración, selecciona cada componente, y solicita la compra. Para el software no se dispone de esa comodidad que acabamos de describir. Con pocas excepciones, no existen catálogos de componentes de software. Se puede comprar software ya desarrollado, pero sólo como una unidad completa, no como componentes que pueden reensamblarse en nuevos programas, aunque ya se está comenzando a ver las primeras implementaciones con éxito de este concepto.

1.2 Componentes del software

A medida que la disciplina del software evoluciona, se crea un grupo de componentes de diseño estándar. Los componentes reutilizables se han creado para que el ingeniero pueda concentrarse en elementos verdaderamente innovadores de un diseño. En el mundo del hardware, la reutilización de componentes es una parte natural del proceso de ingeniería. En el mundo del software, es algo que todavía se tiene que lograr en una escala amplia.

4

La reutilización es una característica importante para un componente de software de alta calidad. El componente debería diseñarse e implementarse para que pueda volver a ser reutilizado en muchos programas diferentes. En los años sesenta se construyeron bibliotecas de subrutinas científicas reutilizables en una amplia serie de aplicaciones científicas y de ingeniería. Esas bibliotecas de subrutinas reutilizaban de forma efectiva algoritmos bien definidos, pero tenían un dominio de aplicación limitado. Hoy en día, se ha extendido la visión de reutilización para abarcar no sólo los algoritmos, sino también estructuras de datos. Los componentes reutilizables modernos encapsulan tanto datos como procesos que se aplican a los datos, permitiendo al ingeniero del software crear nuevas aplicaciones a partir de las partes reutilizables.

1.3 Aplicaciones del software

El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto específico de pasos procedimentales Dos factores importantes a considerar para determinar la naturaleza de una aplicación de software son: el contenido y determinismo de la información. El contenido se refiere al significado y a la forma de la información de entrada y de salida. El determinismo de la información se refiere a la predecibilidad del orden y del tiempo de llegada de los datos. Un programa de ingeniería acepta datos que están en un orden predefinido, ejecuta el algoritmo sin interrupción y produce los datos resultantes en un informe o formato gráfico.

El software, según tipos de aplicaciones, se pueden clasificar como:

Software de sistemas . Es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas (por ejemplo, compiladores, editores y utilidades de gestión de archivos) procesan estructuras de información complejas, pero determinadas. Otras aplicaciones de sistemas, como ciertos componentes del sistema operativo, utilidades de manejo de periféricos y procesadores de telecomunicaciones procesan datos en gran medida indeterminados.

Software de tiempo real . Mide, analiza y controla sucesos del mundo real conforme ocurren. Entre sus elementos se incluyen: un componente de adquisición de datos que recolecta y da formato a la información recibida del entorno externo, un componente de análisis que transforma la información según lo requiera la aplicación, un componente de control/salida que responda al entorno externo y un componente de monitorización que coordina todos los demás componentes, de forma que pueda mantenerse la respuesta en tiempo real.

Software de gestión. El procesamiento de información comercial constituye la mayor de las áreas de aplicación del software. Los «sistemas discretos» (nóminas, inventarios, etc.) han evolucionado hacia el software de sistemas de información de gestión (SIG), que accede a una o más bases de datos grandes que contienen información comercial.

5

Software de ingeniería y científico. Está caracterizado por los algoritmos de «manejo de números». Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática. Sin embargo, las nuevas aplicaciones del área de ingeniería y ciencia se han alejado de los algoritmos convencionales numéricos. El diseño asistido por computadoras (del inglés CAD), la simulación de sistemas y otras aplicaciones interactivas, han comenzado a coger características del software de tiempo real e incluso del software de sistemas.

Software empotrado . Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas, por ejemplo, el control de las teclas de un horno de microondas.

Software de computadoras personales. Este mercado ha florecido en la pasada década. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales, y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

Software de Inteligencia Artificial. Este hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. Actualmente, el área más activa de la IA es la de los sistemas expertos o basados en el conocimiento. Otras áreas de aplicación para este software son el reconocimiento de patrones (imágenes y voz), la prueba de teoremas y los juegos. En los últimos años se ha desarrollado una nueva rama del software de IA llamada redes neuronales artificiales.

1.4 Ingeniería del Software

La Ingeniería del Software es un área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelvan problemas de todo tipo. La Ingeniería del Software es una nueva ingeniería. Una selección de las definiciones de “Ingeniería del Software” se muestra a continuación:

Definición de Fritz Bauer, 1972:Ingeniería del Software trata del establecimiento de principios y métodos de la ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en maquinas reales.

La mayoría de los lectores tienden a seguir esta definición. Aunque no dice sobre los aspectos técnicos de la calidad del software, no se enfrenta directamente con la necesidad de la satisfacción del cliente, omite la mención de la importancia de mediciones y métricas; tampoco expresa la importancia de un proceso avanzado. Sin embargo, la definición de Bauer nos proporciona una línea base.

6

El IEEE [IEEE93] ha desarrollado una definición más completa:

Ingeniería del software: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques como en (1).

1.4.1 Proceso, métodos y herramientas

La ingeniería del software es una tecnología multicapa. Cualquier enfoque de ingeniería debe descansar sobre un empeño de organización de calidad. La gestión total de calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos, la que conduce últimamente al desarrollo de enfoques cada vez más robustos para la ingeniería del software.

El fundamento de la ingeniería del software es la capa proceso. El proceso de la ingeniería del software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería del software. El proceso define un marco de trabajo para un conjunto de áreas clave de proceso que se debe establecer para la entrega efectiva de la tecnología de la ingeniería del software. Las áreas clave del proceso forman la base del control de gestión de proyectos del software y establece el contexto en el que se aplican los métodos técnicos, se producen resultados del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

Los métodos de la ingeniería del software indican cómo construir técnicamente el software. Abarcan un conjunto de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento.

Las herramientas de la ingeniería del software proporcionan un soporte automático o semiautomático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (Computer Aided Software Engineering, CASE). CASE combina software, hardware y una base de datos de ingeniería del software.

La ingeniería es el análisis, diseño, construcción, verificación y gestión de entidades. A la entidad se le debe realizar y responder las siguientes preguntas:

¿Cuál es el problema a resolver? ¿Cuáles son las características de la entidad utilizadas para resolver el problema? ¿Cómo se realizará la entidad (y la solución)? ¿Cómo se construirá la entidad? ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el

diseño y en la construcción de la entidad?

7

¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?

En el curso sólo nos vamos a centrar en una sola entidad: el software de computadoras. Para construir la ingeniería del software adecuadamente, se debe definir un proceso de desarrollo de software, formado por tres fases:

Fase de definición se centra sobre el qué. Fase de desarrollo se centra en el cómo. Fase de mantenimiento se centra en el cambio que va asociado a la corrección.

1.4.2 Modelos de procesos de software.

Para resolver los problemas reales un ingeniero de software o un equipo de ingenieros deben incorporar una estrategia de desarrollo que acompañe al proceso, métodos, herramientas y fases genéricas del proceso del software.

Todo el desarrollo del software se puede caracterizar como un bucle de resolución de problemas donde se encuentran cuatro etapas distintas:

Status quo: estado actual de sucesos. Definición de problemas: identifica el problema específico a resolver. Desarrollo técnico: resuelve el problema a través de la aplicación de alguna tecnología. Integración de soluciones: ofrece los resultados a los que solicitan la solución en primer

lugar.

Basado en estas cuatro etapas se tienen varios modelos de procesos de software.

Modelo lineal secuencial: llamado también ciclo de vida clásico, sugiere un enfoque sistemático y secuencial del desarrollo del software, y consta de las actividades siguientes:

Ingeniería y modelado del sistema/información: el software siempre forma parte de un sistema más grande, hay que determinar de ese sistema que requisitos forman parte del software, y su conexión con otros elementos como personas o bases de datos.

Análisis de los requisitos del software: parte de esto se logra en el paso anterior, en este paso ese proceso de reunión de requisitos se intensifica y se centra solamente en el software, el analista debe comprender el dominio del problema para poder construirlo, y el cliente documenta y repasa los requisitos del sistema.

Diseño: es un proceso de varios pasos que se centra en cuatro atributos distintos de un programa: estructura de datos, arquitectura del software, representaciones de interfaz, y los detalles procedimentales o algoritmos. Este proceso traduce los requisitos en una representación del software que se pueda evaluar por calidad antes de la generación de código, y al igual que los requisitos se documenta, lo que forma parte de la configuración del software.

Generación de código o implementación: Este paso lleva a cabo la tarea de traducción del diseño a una forma legible por la máquina. Si el diseño es detallado este paso es casi mecánico.

8

Pruebas: Después de la generación comienzan las pruebas del programa, centrada en los procesos lógicos internos del software, y en los externos funcionales, para detectar errores y comprobar que la entrada definida produce los resultados deseados.

Mantenimiento: es casi seguro que el software sufra cambios luego de su entrega al cliente, provocado por causas como dispositivos nuevos disponibles, o necesidad de mejoras funcionales o de rendimiento.

Modelo de construcción de prototipos: este modelo comienza con la recolección de requisitos, donde analista y cliente definen las necesidades, luego aparece un diseño rápido, que se centra en la representación de los aspectos visibles al usuario, este diseño lleva a la construcción de un prototipo, que es evaluado por el usuario, y este lo utiliza para refinar los requisitos que desea del software. Este prototipo se puede utilizar en el desarrollo del software final o puede descartarse y realizar una ingeniería del software en vistas a la calidad y la facilidad de mantenimiento.

Modelo DRA : el modelo de desarrollo rápido de aplicaciones es un modelo de desarrollo lineal secuencial con un ciclo de desarrollo extremadamente corto. Para esto se desarrolla un enfoque de construcción basado en componentes, lo que permite reducir el ciclo de entrega del producto final, pero es recomendable solamente en los casos en que la aplicación se puede modularizar adecuadamente, y enfatiza el desarrollo de componentes de programas reutilizables, que son la piedra angular de las tecnologías de objetos.

Modelos de procesos evolutivos: estos modelos son iterativos y permiten a los ingenieros desarrollar versiones cada vez más completas del software.

Modelo incremental: combina el ciclo de vida clásico con la filosofía interactiva de construcción de prototipos, en cada incremento o secuencia lineal que se realiza se logra una parte del objetivo, y se van entregando versiones sucesivas del software.

Modelo en espiral: este modelo combina la naturaleza de la construcción de prototipos con los aspectos controlados del modelo lineal secuencial, se desarrolla el software en cada etapa o espiral como un prototipo que evalúa el cliente y que es el punto de partida de la próxima iteración.

Modelo de ensamblaje de componentes: este incorpora muchas características del modelo en espiral, y configura las aplicaciones a partir de componentes ya existentes que son reutilizados.

1.5 Sistemas Basados en Computadora

La Ingeniería del Software es una consecuencia de un proceso llamado Ingeniería de Sistemas de Computadoras.

El proceso de ingeniería del software es denominado ingeniería de la información cuando el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniería de producto.

9

Ambas ingenierías de la información y de producto intentan poner orden al desarrollo de sistemas basados en computadoras, tanto la ingeniería de la información como la de producto trabajan para asignar un papel al software de computadora y para establecer los enlaces que unen al software con otros elementos de un sistema basado en computadora.

La palabra «sistema» es uno de los términos más usados del léxico técnico. El diccionario Webster define «sistema» como «un conjunto o disposición de cosas relacionadas de manera que forman una unidad o u todo orgánico... un conjunto de hechos, principios, reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes... un método o plan de clasificación o disposición... una manera establecida de hacer algo; método; procedimiento...».

Se define un Sistema Basado en Computadoras como un conjunto o arreglo de elementos que están organizados para realizar un objetivo predefinido procesando información.

1.5.1 Elementos de un sistema basado en computadoras

Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido.

Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo y dispositivos electromecánicos (Ej.: sensores, motores, bombas) que proporcionan una función externa.

Personas. Son los usuarios y operadores del hardware y software.

Base de datos. Una gran colección de información organizada a la que se accede por medio del software.

Documentación. Manuales, formularios y otra información descriptiva que retrata el empleo y/o operación del sistema.

Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema.

Todos estos elementos se combinan de varias maneras para transformar la información. La ingeniería de sistemas de computadoras es un proceso de modelado. El ingeniero crea modelos que:

Definan los procesos que satisfagan las necesidades.Representen el comportamiento de los procesos Definan explícitamente las entradas de información al modeloRepresenten todas las uniones (incluyendo las salidas) que permitan al ingeniero entender

mejor la visión.

10

1.6 Ingeniería de la información

La meta de la ingeniería de la información es definir arquitectura que permitan a las empresas emplear la información eficazmente. Se deben analizar y diseñar tres arquitecturas diferentes dentro del contexto de objetivos y metas de negocio:

Arquitectura de datos Arquitectura de aplicaciones Infraestructura de la tecnología

La arquitectura de datos proporciona una estructura para las necesidades de información de un negocio o de una función de negocio. Los objetos de datos fluyen entre las funciones de negocio, están organizados dentro de una base de datos y son transformados para proporcionar información que satisfaga las necesidades del negocio.

La arquitectura de aplicación comprende aquellos elementos de un sistema que transforma objetos dentro de la arquitectura de datos por algún propósito del negocio. Vamos a considerar que la arquitectura de aplicación es el sistema de programas (software) que realiza esta transformación. .

La infraestructura de la tecnología proporciona el fundamento de la arquitectura de datos y de aplicaciones. La infraestructura comprende el hardware y el software empleados para dar soporte a las aplicaciones y datos. .

1.7 Ingeniería de productos

La meta de la ingeniería de productos es traducir el deseo de un cliente, de un conjunto de capacidades definidas, en un producto operativo. Para conseguir esta meta, la ingeniería de producto (como la ingeniería de la información) debe crear una arquitectura y una infraestructura. La arquitectura comprende cuatro componentes de sistema distintos: software, hardware, datos (bases de datos) y personas. Se establece una infraestructura de soporte e incluye la tecnología requerida para unir los componentes y la información (p. ej.: documentos, CD-ROM, vídeo) que se emplea para dar soporte a los componentes.

2. Gestión de proyectos de software

La gestión eficaz de un proyecto de software se centra en las tres 'p': personal, problema y proceso. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. Finalmente, el administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.

11

Personal

La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60. El proceso del software y todos los proyectos de software lo componen participantes que pueden clasificarse en una de cinco categorías:

1. Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.

2. Gestiones (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.

3. Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.

4. Clientes, que especifican los requisitos para la ingeniería del software.5. Usuarios finales, que interaccionan con el software una vez que se ha entregado para

la producción,

Problema

Antes de poder planificar un proyecto, se deberían establecer sus objetivos y su ámbito, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del costo, una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso.

El desarrollador de software y el cliente deben reunirse para definir los objetivos del proyecto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán.

El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan el problema, y más importante, intenta abordar estas características de una manera cuantitativa.

Una vez que se han entendido los objetivos y el ámbito del proyecto, se consideran las soluciones alternativas. Aunque se estudia con poco detalle, las alternativas permiten a los gestores y a los profesionales seleccionar el «Mejor» enfoque, dadas las limitaciones impuestas por las fechas límite de entrega, restricciones del presupuesto, disponibilidad de personal, interfaces técnicas y otros muchos factores.

Proceso

12

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas, hitos, entregas y garantía de calidad permite a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras tales como garantía de calidad del software, gestión y configuración del software y medición cubren el modelo de proceso y se desarrollan a todo lo largo del mismo.

2.1 Planificación de proyectos

El proceso de gestión de proyecto de software comienza con un conjunto de actividades que se denominan planificación del proyecto. La primera de estas actividades es la estimación. Siempre que estimamos, echamos un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.

Aunque la estimación es más un arte que una ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes y de tiempos. Y, dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena ingeniería del software, no es en absoluto aconsejable embarcarse sin ella.

La estimación de recursos, costes, y planificación temporal de un esfuerzo en desarrollo de software requiere experiencia, acceder a una buena información histórica y el coraje de confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos. La estimación conlleva un riesgo inherente y es este riesgo el que lleva a la incertidumbre.

En la estimación se toman en cuenta además del procedimiento técnico a utilizar en el proyecto, los recursos, costos y planificación. El tamaño del proyecto constituye un factor importante que puede afectar la precisión de las estimaciones. En la medida que el tamaño aumenta, se incrementa más rápido la independencia de los elementos del software.

2.1.1 Objetivos de la planificación del proyecto

El objetivo de la planificación del proyecto de software es brindar un entorno de trabajo que facilite al gestor hacer estimaciones de recursos, costos y planificación temporal. Las estimaciones se realizan al comienzo de un proyecto de software, y deben ser actualizadas en la medida que el proyecto avanza. Las estimaciones deberían definir las escenas del mejor y peor caso, de forma tal que se puedan definir mejor los limites de los resultados del proyecto.

13

2.2 Actividades asociadas a la planificación de proyectos de software.

2.2.1 Ámbito del Software.

La primera actividad que se lleva a cabo durante la planificación del proyecto de software es el ámbito del software. El ámbito se define respondiendo las siguientes cuestiones.

Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de

negocios mayor y que limitaciones se imponen como resultado del contexto? Objetivos de información. ¿Qué objetos de datos visibles al cliente se obtienen del

software? ¿Qué objetos de datos son requeridos de entrada? Función y rendimiento. ¿Qué función realiza el software para transformar la

información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?

Durante esta etapa, se deben evaluar la función y el rendimiento que se asignaron al software durante la Ingeniería del Sistema de Computadora, con el propósito de establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos

El ámbito del software describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar más detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

Un prerrequisito para la estimación es el ámbito del software, un elemento importante a tener en cuenta es la obtención de la información necesaria para el software, donde el analista y el cliente se reúnen y mediante la realización de preguntas llegan a precisar y determinar los limites del sistema para su desarrollo, así como a una mejor comprensión por el analista de sistema.

2.2.2 Recursos

La segunda actividad de la planificación del desarrollo de software es la estimación de los recursos requeridos para llevar a cabo el desarrollo de software, esto simula a una pirámide donde las herramientas (hardware y software), son la base y proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel se encuentran los componentes reutilizables, y en la parte más alta de la pirámide se encuentran los recursos humanos.

Las características de cada recurso están dadas por: Descripción del recurso. Informes de la disponibilidad. Fecha en la que se requiere el recurso. Tiempo que será aplicado el recurso.

14

Recursos Humanos

Los recursos humanos son la cantidad de personas necesarias para el desarrollo de un proyecto de software, sólo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), también se selecciona la posición dentro de la organización y la especialidad que desempeñará cada profesional durante el desarrollo del software.

Recursos de software reutilizables

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, o sea, la creación y la reutilización de bloques de construcción de software. Se sugieren cuatro categorías de recursos de software a tener en cuenta durante la planificación:

1. Componentes ya desarrollados2. Componentes ya experimentados. 3. Componentes con experiencia parcial4. Componentes nuevos

Recursos de entorno

El entorno es donde se apoya el proyecto de software, conocido como entorno de ingeniería del software (EIS), el cual incorpora hardware y software. El hardware proporciona una plataforma con las herramientas (software) necesarias para desarrollar los productos que son el resultado de una buena práctica de la ingeniería del software. Como la mayoría de las organizaciones de software tienen aspectos que requieren acceso a EIS, un planificador de proyecto debe determinar la ventana temporal requerida para el hardware y el software, y verificar que estos recursos estarán disponibles.Cuando se le aplica la ingeniería a un sistema basado en computadora, el equipo de software puede requerir acceso a los elementos en desarrollo por otros equipos de ingeniería.

2.3 Estimación del proyecto de software.

El coste del software constituía un pequeño porcentaje del coste total de los sistemas basados en computadora. En la actualidad, el software constituye el elemento más caro de la mayoría de los sistemas informáticos. Un gran error en la estimación del coste puede ser lo que marque la diferencia entre beneficios y pérdidas, y sobrepasarse en el coste puede ser catastrófico en el equipo de desarrollo.La estimación del coste y del esfuerzo del software nunca será una ciencia exacta. Son demasiadas las variables humanas, técnicas, de entorno, políticas que pueden afectar al coste final del software y al esfuerzo aplicado para desarrollarlo.

15

Las siguientes opciones son útiles para realizar estimaciones seguras de costes y esfuerzos:

1. Deje la estimación para más adelante (lógico que podemos realizar una estimación al cien por cien fiable luego de haber terminado el proyecto).

2. Guiar las estimaciones en proyectos similares ya concluidos.3. Usar técnicas de descomposición relativamente sencillas para generar las

estimaciones de coste y de esfuerzo del proyecto.4. Realice un modelo empírico para el cálculo de costes y esfuerzos del software.

Lamentablemente, la primera opción, aunque atractiva, no es práctica, debido a que las estimaciones de costes se han de realizar a priori. No obstante, hay que reconocer que cuanto más tiempo transcurra, más elementos conocemos, y cuanto más sepamos, menor será la probabilidad de cometer graves errores en las estimaciones.

La segunda opción funciona si el proyecto actual es bastante similar a los esfuerzos anteriores y si otras influencias del proyecto son similares.

Las opciones restantes son métodos viables para la estimación del proyecto de software. Las técnicas de descomposición utilizan un enfoque de «divide y vencerás» para la estimación del proyecto de software. Se pueden utilizar los modelos empíricos de estimación como complemento de las técnicas de descomposición, ofreciendo un enfoque de estimación potencialmente valioso por derecho propio

2.3.1 Técnicas de estimación. Estimación basada en el proceso.

La estimación basada en el proceso es la técnica más común para estimar un proyecto, es decir, el proceso se descompone en un conjunto relativamente pequeño de tareas, y en el esfuerzo necesario para estimar cada tarea. Esta estimación se inicia con una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Por último, se calculan los costos y el esfuerzo de cada función y en general la del proceso de software.

2.4 Modelos empíricos de estimación

Los datos empíricos que soportan la mayoría de los modelos de estimación se obtienen de una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por tanto, los resultados obtenidos de dichos modelos se deben utilizar con prudencia

2.4.1 Modelo COCOMO

Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO (Constructive Cost Model) o modelo constructivo de costos. La jerarquía de modelos de Boehm esta formada por:

16

Modelo I. Es el modelo COCOMO básico que calcula el esfuerzo y el costo del desarrollo de software en función del tamaño del programa, expresado en las líneas estimadas.

Modelo II. Es el modelo intermedio que calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costos que intervienen en la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

Modelo III. Es el modelo avanzado que incorpora las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.) del proceso de ingeniería de Software.

2.5 Herramientas automáticas de estimación

Las técnicas de descomposición y los modelos empíricos de estimación se pueden implementar con software, las herramientas automáticas de estimación permiten al planificador estimar costes y esfuerzos, y llevar a cabo un análisis del tipo «qué pasa si» con importantes variables del proyecto, como es la fecha de entrega y la selección de personal.

Las herramientas automáticas de estimación requieren una o más clases de datos como:

Una estimación cuantitativa del tamaño del proyecto o de la funcionalidad. Características cualitativas del proyecto: complejidad, la fiabilidad requerida y el grado

de criticidad del negocio. Descripción del personal de desarrollo y/o del entorno de desarrollo.

Con estos datos, el modelo implementado por la herramienta automática de estimación brinda estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costes, la carga de personal, la duración y en algunos casos, la planificación temporal de desarrollo y el riesgo asociado.

3. Análisis de sistemas

El análisis de sistemas se lleva a cabo con los siguientes objetivos:

Identificar la necesidad del cliente. Evaluar el concepto del sistema para establecer la viabilidad. Realizar el análisis técnico y económico. Asignar funciones al hardware, software, personal, bases de datos y otros elementos del

sistema. Establecer restricciones de presupuesto y planificación temporal.

17

Crear una definición del sistema que forme el fundamento de todo el trabajo de ingeniería.

Para alcanzar los objetivos de la etapa del análisis se requiere de un amplio conocimiento del área de hardware, software, administración de bases de datos y de la ingeniería humana para interactuar con el personal que solicita la realización del sistema.

Los métodos de análisis se relacionan por un conjunto de principios operativos:

l. Debe representarse y entenderse el dominio de información de un problema.2. Deben definirse las funciones que debe realizar el software.3. Debe representarse el comportamiento del software (como consecuencia de

acontecimientos externos).4. Deben dividirse los modelos que representan información, función y comportamiento

de manera que se descubran los detalles por capas (o jerárquicamente).5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la

implementación.

Además de los principios operativos de análisis mencionados anteriormente, se sugiere un conjunto de principios directrices para la «ingeniería de requisitos»:

Entender el problema antes de empezar a crear el modelo de análisis. Hay tendencia a precipitarse en busca de una solución, incluso antes de entender el problema.

Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-máquina. Como el concepto de calidad del software se basa a menudo en la opinión sobre la «amigabilidad» de la interfaz, el desarrollo de prototipos (y la iteración que se produce) es altamente recomendable.

Registrar el origen y la razón de cada requisito. Este es el primer paso para establecer un seguimiento hasta el cliente

Use múltiples planteamientos de requisitos. La construcción de modelos de datos, funcionales y de comportamiento le proporcionan al ingeniero del software tres puntos de vista diferentes. Esto reduce la probabilidad de que se olvide algo y aumenta la probabilidad de reconocer la falta de consistencia.

Dar prioridad a los requisitos. Las fechas ajustadas de entrega pueden impedir la implementación de todos los requisitos del software. Si se aplica un modelo de proceso incremental, se deben identificar los requisitos que se van a entregar en la primera entrega.

Trabajar para eliminar la ambigüedad. Como la mayoría de los requisitos están descritos en un lenguaje natural, abunda la oportunidad de ambigüedades. El empleo de revisiones técnicas formales es una manera de descubrir y eliminar la ambigüedad.

3.1 Identificación de las necesidades (análisis de requisitos)

Lo primero en el análisis del sistema es la identificación de la necesidad del usuario, donde el analista se reúne con el cliente y usuarios finales para entender los objetivos del producto y definir las metas necesarias para alcanzarlos.

18

Una vez que se han identificado las metas globales, el analista pasa a la evaluación de la información suplementaria:

Tecnología para construir el sistema.Recursos especiales de desarrollo y fabricación necesarios.Límites de presupuesto y de planificación temporal.Si el nuevo sistema es un producto a desarrollar para venderlo a muchos clientes, se debe

analizar: ¿Cuál es el mercado potencial del producto? ¿Cómo es comparativamente este producto con los de la competencia? ¿Qué posición ocupa este producto en la línea general de producción de la compañía?

El análisis de requisitos permite al ingeniero del software (analista) la definición del software y construir los modelos de los dominios de datos, funcional y de comportamiento que van a ser tratados por el software. El análisis de requisitos proporciona modelos al diseñador del software que pueden traducirse en el diseño de datos, arquitectónico, de interfaz y procedimental.

El análisis de requisitos del software puede dividirse en cinco áreas: Reconocimiento del problema Evaluación y síntesis Modelado Especificación Revisión.

El analista estudia la especificación del sistema. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. Se debe establecer la comunicación para el análisis de manera que nos garantice el reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el usuario o el cliente.

En la evaluación del problema y la síntesis de la solución el analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de sistema. Estas tareas sirven para describir el problema de manera que se pueda sintetizar un enfoque o solución global.Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema para entender el flujo de datos y de control, el tratamiento funcional.

En esta etapa no es posible una especificación detallada del sistema, el cliente puede no estar seguro de lo que quiere, el desarrollador puede no estar seguro de que un enfoque específico consiga apropiadamente el funcionamiento y rendimiento adecuados. Una vez que se han identificado las metas globales, el analista pasa a la evaluación de la información suplementaria: ¿Existe la tecnología para construir el sistema? ¿Qué recursos especiales de desarrollo y fabricación serán necesarios? ¿Qué límites se han puesto al presupuesto y a la planificación temporal? Si el nuevo sistema es un producto a desarrollar

19

para venderlo a muchos clientes, se plantean además las siguientes cuestiones: ¿Cuál es el mercado potencial del producto? ¿Cómo es comparativamente este producto con los de la competencia? ¿Qué posición ocupa este producto en la línea general de producción de la compañía?

La información reunida durante el paso de identificación de necesidades es especificada en un documento conceptual del sistema. El documento conceptual original es preparado a veces por el cliente antes de las reuniones con el analista. Invariablemente, la comunicación cliente-analista origina modificaciones en el documento.

La técnica de análisis más usada para cubrir el hueco de comunicación entre el cliente y el desarrollador y para empezar el proceso de comunicación es llevar a cabo una reunión o entrevista preliminar. El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo, el analista podría preguntar:

¿Quién está detrás de la solicitud de este trabajo? ¿Quién utilizará la solución? ¿Cuál será el beneficio económico del éxito de una solución? ¿Hay alguna otra alternativa para la solución que necesita?

El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sobre la solución:

¿Cómo caracterizaría una «buena» salida (resultado) generada para una buena solución?

¿A qué tipo de problema(s) va dirigida esta solución? ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución? ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de

enfocar la solución?

El último conjunto de preguntas se concentra en la eficacia de la reunión. Gauge y Weinberg las denominan «Meta-preguntas» y proponen la siguiente lista (abreviada):

¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son «oficiales»?

¿Son adecuadas mis preguntas para el problema que tiene usted'? ¿Estoy preguntando demasiado? ¿Hay alguien más que pueda proporcionar información adicional'? ¿Hay algo más que debería preguntarle?

Estas preguntas (y otras) ayudarán a «romper el hielo» e iniciar la comunicación tan esencial para el éxito del análisis. Pero el formato de reunión tipo «pregunta y respuesta» no es un enfoque que haya tenido mucho éxito. De hecho, esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro y sustituirse después por

20

una modalidad que combine elementos de resolución del problema, negociación y especificación.

3.2 Estudio de la viabilidad

Todos los proyectos son posibles en caso de tener infinitos recursos y tiempo. Desafortunadamente el desarrollo de un sistema basado en computadoras es muy probable que exista escasez de recursos y de fechas de entrega. Por lo que es necesario evaluar la viabilidad de un proyecto cuanto antes.

La viabilidad y el análisis de riesgo están relacionados de muchas maneras. Si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce. Analizaremos lo siguiente:

Viabilidad económica. Es la evaluación de los costos de desarrollo, con relación a los ingresos netos o beneficios obtenidos del sistema desarrollado.

Viabilidad técnica. Es el análisis y estudio de funciones, rendimiento y restricciones que puedan afectar la realización de un sistema aceptable.

Viabilidad legal. Es la determinación de cualquier posibilidad de infracción, violación o responsabilidad legal en que se podría incurrir al desarrollar el sistema.

Alternativas. Una evaluación de los enfoques alternativos del desarrollo del sistema.

No es necesario un estudio de viabilidad para sistemas en que la justificación económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable.

La justificación económica es generalmente la consideración fundamental para la mayoría de los sistemas. Incluye una amplia gama de aspectos a tener en cuenta como son el análisis de costes/beneficios, las estrategias de ingresos de la empresa a largo plazo, el impacto en otros productos o centros de beneficios, costo de recursos necesarios para el desarrollo y crecimiento potencial del mercado.

La viabilidad tecnológica es frecuentemente el área más difícil de valorar en esta etapa del proceso de ingeniería del producto. Como los objetivos, funciones y rendimiento son poco claros, cualquier cosa parece posible si se hacen las suposiciones correctas. Es esencial que el proceso de análisis y definición se realice en paralelo con una valoración de la viabilidad técnica. De esta manera se pueden juzgar especificaciones concretas a medida que se establecen.

Las consideraciones que están asociadas normalmente con la viabilidad técnica son:

Riesgo de desarrollo. ¿Puede diseñarse el elemento del sistema de manera que se consigan la función y rendimiento necesarios dentro de las restricciones descubiertas durante el análisis?

21

Disponibilidad de recursos. ¿Tenemos disponible una plantilla cualificada para desarrollar el elemento del sistema en cuestión? ¿Tenemos disponibles otros recursos necesarios (hardware y software) para construir el sistema?

Tecnología. ¿Ha progresado la tecnología respectiva hasta un punto que sea capaz de soportar el sistema?

La viabilidad legal comprende una gama muy amplia de aspectos que incluyen contratos, responsabilidades legales, infracciones y un montón de trampas frecuentemente desconocidas para el personal técnico.

El grado con que se consideran las alternativas está a menudo limitado por restricciones de tiempo y costes; sin embargo, no debería despreciarse una variación legítima por no estar «subvencionada».

El estudio de viabilidad es revisado primero por el jefe del proyecto (para valorar la fiabilidad del contenido) y por la dirección (para valorar el estado del proyecto). El estudio debería concluir en una decisión «adelante / abandonamos».

3.3 Análisis técnico y económico.

Una información importante contenida en un estudio de viabilidad es el análisis de costo/ beneficio: una valoración de la justificación económica para un proyecto de sistema basado en computadora.

El análisis costes beneficios determina los costes para el desarrollo del proyecto y los pondera con los beneficios tangibles (medibles directamente en dinero) y beneficios intangibles del sistema. El análisis costo/beneficio es complicado por criterios que varían con las características del sistema a desarrollar, el tamaño relativo del proyecto y los beneficios esperados de la inversión como parte del plan estratégico de la compañía. Además, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles (por ejemplo, mejor calidad de diseño gracias a una optimización frecuente, mayor satisfacción del cliente gracias al control programable y mejores decisiones de negocio gracias a los datos de ventas preanalizados y reformateados). Las comparaciones cuantitativas directas pueden ser difíciles de conseguir.

Durante el análisis técnico, el analista evalúa los principios técnicos del sistema al mismo tiempo que se recoge información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad.

El análisis técnico empieza con una valoración de la viabilidad técnica del sistema propuesto. ¿Qué tecnologías se requieren para lograr el funcionamiento y rendimiento del sistema?

¿Qué nuevos materiales, métodos, algoritmos o procesos se necesitan y cuál es su riesgo de desarrollo?

¿Cómo afectarán estos aspectos tecnológicos a los costes?

22

3.4 Modelado de la arquitectura del sistema.

Los sistemas basados en computadora pueden moderarse como la transformación de la información empleando una arquitectura del tipo entrada-proceso-salida.

Para desarrollar el modelo de sistema, se emplea un esquema de arquitectura, donde el ingeniero de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del esquema: (1) Interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema, (4) salida y (5) mantenimiento y autocomprobación.

Como casi todas las técnicas de modelado usadas en la ingeniería del software y de sistemas, el esquema de arquitectura permite al analista crear una jerarquía en detalle. En la parte alta de la jerarquía reside el diagrama de contexto de la arquitectura (DCA).

El diagrama de contexto «establece el límite de información entre el sistema que se está implementando y el entorno en que va a operar». Es decir, el DCA define todos los suministradores externos de información que emplea el sistema, todos los consumidores externos de información creados por el sistema y todas las entidades que se comunican a través de la interfaz o realizan mantenimiento y autocomprobación.

El ingeniero de sistemas refina el diagrama de contexto de arquitectura con más detalle, y se identifican los subsistemas principales que permiten funcionar al sistema.

3.5 Especificación del sistema.

Las especificaciones del sistema se registran en un documento que sirve de base para ingeniería hardware, software, base de datos, e ingeniería Humana. En este documento se describen las funciones y rendimiento de un sistema basado en computadoras y las dificultades que se pueden presentar durante su desarrollo. Al concluir la etapa del análisis se realizan las especificaciones de los requisitos del software.

Puede decirse que un proyecto de desarrollo de un sistema de información comprende varios pasos durante la etapa del análisis, el cual facilita traducir las necesidades del cliente en un modelo de sistema que hace uso de varios componentes: software, hardware, personas, base de datos, documentación y procedimientos

3.6 Creación de prototipos del software.

El análisis hay que hacerlo independientemente del paradigma de ingeniería del software que se aplique, sin embargo, la forma que toma este análisis varía. En algunos casos es posible aplicar los principios operativos del análisis y obtener un modelo de software del que se pueda desarrollar un diseño. En otras situaciones, se realizan recopilaciones de

23

requisitos, se aplican los principios del análisis y se construye un modelo del software a fabricar denominado prototipo para que lo valore el cliente y el desarrollador. Finalmente, hay circunstancias que requieren la construcción de un prototipo al comienzo del análisis, ya que el modelo es el único medio a través del cual se pueden obtener eficazmente los requisitos. El modelo evoluciona después hacia la producción del software.

El paradigma de creación de prototipos puede ser cerrado o abierto. El enfoque cerrado se denomina a menudo prototipo desechable. Este prototipo sirve únicamente como una basta demostración de los requisitos. Después se desecha, y se hace una ingeniería del software con un paradigma diferente. Un enfoque abierto, denominado prototipo evolutivo, emplea el prototipo como primera parte de una actividad de análisis a la que seguirá el diseño y la construcción. El prototipo del software es la primera evolución del sistema terminado.

Antes de poder elegir un enfoque abierto o cerrado, es necesario determinar si se puede crear un prototipo del sistema a construir.

En general, cualquier aplicación que cree pantallas visuales dinámicas, interactúe intensamente con el ser humano, o demande algoritmos de procesamiento de combinaciones que deban crearse de manera progresiva, es un buen candidato para la creación de un prototipo. Sin embargo, estas áreas de aplicación deben ponderarse con la complejidad de la aplicación. Si una aplicación candidato (una con las características reseñadas anteriormente) va a requerir el desarrollo de decenas de miles de líneas de código antes de poder realizar cualquier función demostrable, es muy probable que sea demasiado compleja para crear un prototipo. Si se puede hacer una partición a su complejidad, puede ser posible crear prototipos de porciones del software.

Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que (1) se destinen recursos del cliente a la evaluación y refinamiento del prototipo, y (2) el cliente sea capaz de tomar decisiones inmediatas sobre los requisitos.

Existe un conjunto de seis cuestiones que ayudarán en la selección del enfoque de creación de prototipos:

1. ¿Entiende el cliente y el desarrollador el dominio de la aplicación para la que se va a construir el software?

2. ¿Se puede modelar el problema?3. ¿Está el cliente suficientemente seguro de los requisitos básicos del sistema?4. ¿Están suficientemente establecidos los requisitos y tienen posibilidad de ser

razonablemente estables?5. ¿Hay requisitos ambiguos?6. ¿Hay contradicciones en los requisitos?

1.4 Diseño de sistemas

24

El diseño se ha descrito como un proceso multifase en el que se sintetizan representaciones de la estructura de datos, estructura del programa, características de la interfaz y detalles procedimentales desde los requisitos de la información.

El diseño del software es el núcleo técnico del proceso de ingeniería del software y se aplica independientemente del paradigma de desarrollo utilizado.

Cada uno de los elementos del modelo de análisis proporciona información necesaria para crear un modelo de diseño. Los requisitos del software, manifestados por los datos y los modelos funcionales y de comportamiento, componen la fase de diseño. Mediante el empleo de uno de los métodos de diseño la fase de diseño produce:

Diseño de datos Diseño arquitectónico Diseño de interfaz Diseño procedimental.

1.4.1 Diseño de datos.

El diseño de datos es la primera (y alguien diría que la más importante) de las cuatro actividades de diseño que se llevan a cabo durante la ingeniería del software.

El impacto de la estructura de datos en la estructura del programa y la complejidad procedimental hace que el diseño de los datos tenga una profunda influencia en la calidad del software. Los conceptos de ocultación de información y abstracción de datos proporcionan el fundamento para un enfoque del diseño de datos.

El proceso de diseño de datos lo resume Wasserman [WAS80]:

La actividad principal del diseño de datos es seleccionar representaciones lógicas de objetos de datos (estructuras de datos) identificadas durante la fase de definición y especificación de requisitos. El proceso de selección puede incluir el análisis de estructuras alternativas para determinar el diseño más eficaz o puede incluir simplemente el empleo de un conjunto de módulos (un «paquete») que proporcione las operaciones deseadas sobre alguna representación de un objeto.

Una actividad relacionada importante durante el diseño es identificar aquellos módulos del programa que deben operar directamente sobre las estructuras de datos lógicas. De esta manera se puede restringir el alcance de efecto de las decisiones individuales sobre el diseño de datos.

Independientemente de las técnicas de diseño que se emplean, datos bien diseñados pueden conducir a una mejor estructura y modularidad del programa, y a una menor complejidad procedimental.

25

Wasserman ha propuesto un conjunto de principios que pueden emplearse para especificar y diseñar datos. En realidad, el diseño de datos empieza durante la creación del modelo de análisis. Recordando que el análisis de requisitos y el diseño a menudo se solapan, consideramos el siguiente conjunto de principios [WAS80] para la especificación de datos:

1. Los principios del análisis sistemático aplicados a la función y al comportamiento deberían aplicarse también a los datos. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas.

2. Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa.

3. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño.

4. La representación de las estructuras de datos deberían conocerla sólo aquellos módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.

5. Debería desarrollarse una biblioteca de estructuras de datos útiles y de las operaciones que se les pueden aplicar. Las estructuras de datos y las operaciones deberían considerarse como recursos para el diseño del software.

6. Un diseño del software y un lenguaje de programación deberían soportar la especificación y realización de los tipos abstractos de datos.

El diseño de datos transforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidad-relación y el contenido detallado de datos del diccionario de datos proporciona la base para la actividad de diseño de datos.

1.4.2 Diseño arquitectónico

El objetivo del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos. Además, el diseño arquitectónico combina la estructura del programa y las estructuras de datos, definiendo interfaces que permiten el flujo de datos a través del programa.

El diseño orientado al flujo de datos es un método de diseño arquitectónico que permite una cómoda transición desde el modelo de análisis a una descripción del diseño de la estructura del programa.

La transición desde el flujo de información (representado como un diagrama de flujo de datos) a una estructura se realiza en un proceso de cinco pasos: (1) se establece el tipo de flujo de información; (2) se indican los límites del flujo; (3) se convierte el DFD en la estructura del programa; (4) se define la jerarquía de control descomponiéndola mediante particionamiento; y (5) se refina la estructura resultante usando medidas y heurísticas de diseño. El tipo de flujo de información es lo que determina el método de conversión requerido en el paso 3.

26

1.4.3 Diseño de la interfaz

El diseño arquitectónico proporciona al ingeniero del software una imagen de la estructura del programa. Como el plano para una casa, el diseño general no está completo sin la representación de las puertas, ventanas y conexiones a servicios para agua, electricidad y teléfono (sin mencionar la televisión por cable). Las «puertas, ventanas y conexiones a servicios» para el software de computadora componen el diseño de la interfaz del sistema.

El diseño de la interfaz se concentra en tres áreas importantes:

(1) el diseño de interfaces entre los módulos software; (2) el diseño de interfaces entre el software y otros productores y consumidores no humanos de información (por ejemplo, otras entidades externas); y (3) el diseño de la interfaz entre el hombre (Ej. el usuario) y la computadora.

El diseño de la interfaz de usuario tiene tanto que ver con el estudio de las personas como con los aspectos de la tecnología. ¿Quién es el usuario? ¿Cómo aprende el usuario a interactuar con el nuevo sistema basado en computadora?¿Cómo interpreta el usuario la información producida por el sistema? ¿Qué es lo que espera el usuario del sistema? Éstas son unas pocas de las cuestiones que deben hacerse y contestarse como parte del diseño de la interfaz de usuario.

El proceso general para diseñar la interfaz de usuario empieza con la creación de diferentes modelos de función del sistema (tal y como se percibe desde fuera). Se definen las tareas orientadas al hombre y a la máquina, requeridas para conseguir la función del sistema; se consideran los aspectos de diseño aplicables a todos los diseños de interfaz; se usan herramientas para crear el prototipo e implementar el modelo de diseño y se evalúa la calidad del resultado.

El diseño de interfaz describe cómo se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean. Una interfaz implica un flujo de información. Por tanto, los diagramas de flujo de datos y control proporcionan la información necesaria para el diseño de la interfaz.

4.4 Diseño procedimental

El diseño procedimental se realiza después de los diseños de datos, arquitectónico y de interfaz. En un mundo ideal, la especificación procedimental necesaria para definir los detalles de los algoritmos se expresaría en un lenguaje natural. Después de todo, todos los miembros de una organización de desarrollo de software hablan un lenguaje natural (en teoría, al menos), las personas fuera del mundo del software podrían entender mejor la especificación, y no sería necesario un nuevo aprendizaje.

Desgraciadamente, hay un pequeño problema. El diseño procedimental debe especificar los detalles procedimentales sin ambigüedades, y la falta de ambigüedad en el lenguaje

27

natural no es natural. Con un lenguaje natural podemos escribir un conjunto de pasos procedimentales de demasiadas formas diferentes.

La importancia del diseño del software se puede decir con una sola palabra: calidad. El diseño es el lugar donde se fomenta la calidad en el desarrollo del software. El diseño nos proporciona representaciones del software en las que se pueden valorar la calidad. El diseño es la única manera de traducir con precisión los requisitos del cliente en un sistema o producto software

El diseño del software es un proceso y un modelo a la vez. El modelo del diseño es el equivalente a los planos de una casa para un arquitecto. Empieza representando la totalidad de lo que se va a construir (ejemplo, una representación tridimensional de la casa) y lentamente lo va refinando para proporcionar una directriz para construir cada detalle

1.4.4 Arquitectura del software

La arquitectura del software contribuye a «la estructura global del software del sistema». En su forma más simple, la arquitectura es la estructura jerárquica de los componentes del programa (módulos), la manera de interactuar de estos componentes, y la estructura de los datos usados por estos componentes. La relación de control entre los módulos se expresa de la siguiente manera: un módulo que controla otro módulo se dice que es superior a él; inversamente, un módulo controlado por otro se dice que es inferior.

La jerarquía de control también representa dos características sutilmente diferentes de la arquitectura del software: visibilidad y conectividad. La visibilidad indica el conjunto de componentes de programa que pueden invocarse o usarse sus datos por un componente dado, incluso cuando esto se realiza indirectamente. La conectividad indica el conjunto de componentes que son invocados directamente o usados sus datos por un componente determinado.

La modularidad juega un papel importante en el diseño, se ha convertido en un enfoque admitido en todas las disciplinas de la ingeniería. Un diseño modular reduce la complejidad, facilita los cambios y hace más fácil la implementación al fomentar el desarrollo en paralelo de diferentes partes de un sistema.

1.4.6 Criterios para evaluar la calidad del diseño.

Debe tener una estructura jerárquica que haga un uso inteligente del control entre los componentes del software.

Debe ser modular, o sea hacer una partición lógica del software en elementos que realicen funciones y subfunciones especificas.

Debe contener abstracciones de datos y procedimientos. Los módulos deben presentar características de funcionamiento independiente. Las interfaces no deben ser complejas para las conexiones entre los módulos y el

28

entorno exterior. Debe hacerse usando un método según la información obtenida durante el análisis de

requisitos de Software.

1.5 Desarrollo de software

La fase de desarrollo se centra en el cómo, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función como una arquitectura del software, cómo han de implementarse detalles procedimentales, cómo han de caracterizarse las interfaces, cómo ha de traducirse el diseño en un lenguaje de programación y cómo ha de realizarse la prueba.

Los encargados de desarrollar software pueden instalar software comprado a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Los programadores son responsables de la documentación de los programas y de explicar su codificación, esta documentación es esencial para probar el programa y hacer el mantenimiento.

1.6 Prueba del software

Luego de generar el código se comienzan las pruebas del programa, este paso se centra en los procesos lógicos internos del software, asegurando que todas las sentencias y procesos externos funcionales se han comprobado, se realizan las pruebas para la detección de errores y el sentirse seguro de que las entradas produzcan resultados reales de acuerdo con los resultados requeridos.

La prueba abarca un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemática. Se debe definir en el proceso de la ingeniería del software una plantilla para la prueba del software: es decir, un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba.

Existen varias estrategias de prueba del software, todas proporcionan al desarrollador de software una plantilla para la prueba y tienen las características generales siguientes:

La prueba comienza en el nivel de módulo y trabaja «hacia fuera», hacia la integración de todo el sistema basado en computadora.

Según el momento son apropiadas diferentes técnicas de prueba. La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes

proyectos) un grupo independiente de pruebas.

29

Una estrategia de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Una estrategia debe proporcionar una guía al profesional y proporcionar un conjunto de hitos para el jefe de proyecto.

1.6.1 Objetivos de la prueba.

La prueba es un proceso de ejecución de un programa con la intención de descubrir un error.

Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

Una prueba tiene éxito si descubre un error no detectado hasta entonces.

1.6.2 Verificación y validación

La prueba del software es un elemento de un tema más amplio que, a menudo, se le conoce como verificación y validación. La verificación se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica. La validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.

1.7 Implantación

La implantación es la última etapa del desarrollo de sistemas. Es el resultado de instalar el software y equipamiento nuevo, y llevar a cabo el proceso automatizado.

Para implantar el sistema de información hay que estar bien seguro que el sistema sea operacional, o sea, que funcione de acuerdo a los requerimientos del análisis.

A pesar de que el sistema esté bien diseñado y cuente con interfaces adecuadas, es importante para la implantación realizar una buena capacitación a todos los usuarios para su puesta en explotación y garantizar el mantenimiento.

1.7.1 Capacitación de usuarios del sistema

Durante la fase de implementación es responsabilidad del analista la capacitación de los usuarios del sistema comenzando desde las personas que capturan los datos hasta aquellos que toman las decisiones sin usar una computadora. Es recomendable no incluir durante el entrenamiento a grupos de personas de habilidad e intereses de trabajo diferentes; ya que ambos grupos quedarían perdidos.

30

A pesar de que una empresa puede contratar los servicios de instructores externos, el analista es la persona que puede ofrecer la mejor capacitación debido a que conoce al usuario del sistema y al sistema mejor que cualquier otro.

No obstante la organización puede contratar otros servicios de capacitación como son:

Vendedores: Son aquellos que proporcionan capacitación gratuita fuera de la empresa de uno o dos días.

Instructor pagado externamente: Son aquellos que pueden enseñar todo acerca de las computadoras, en caso necesario para algunos usuarios.

Instructores en casa: Están familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero le faltaría experiencia en Sistemas de Información que es realmente la necesidad del usuario.

1.7.2 Evaluación del sistema.

La evaluación del sistema se lleva a cabo para identificar puntos débiles y fuertes del mismo. Esta evaluación se lleva en cualquiera de las siguientes dimensiones:

Evaluación operacional:

Se evalúa la manera en que funciona el sistema, facilidad de uso, tiempo de respuesta ante una petición, formatos en que se muestra la información de entradas y salidas, y el nivel de utilidad.

Impacto organizacional:

Se miden los beneficios operacionales para la empresa en áreas tales como las finanzas, eficiencia en el desempeño laboral e impacto competitivo. Se evalúa el impacto, rapidez y organización en el flujo de información interna y externa.

Desempeño del desarrollo:

Se evalúa el proceso de desarrollo adecuado considerando criterios como, tiempo y esfuerzo en el desarrollo de acuerdo al presupuesto y estándares y otros criterios de administración de proyectos. Se realiza la valoración de los métodos y herramientas usados en el desarrollo del sistema.

1.8 Mantenimiento

Es lógico que el software sufra cambios después de ser entregado al cliente. Se producirán cambios porque se han encontrado errores, porque el software debe adaptarse para ajustarse a los cambios de su entorno externo o porque el cliente requiere mejoras funcionales o de rendimiento.

31

La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente.

Esta fase vuelve a aplicar los pasos de las fases de definición y de desarrollo, pero en el contexto del software ya existente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:

Corrección. A pesar de llevar a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo modifica el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir para permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

El mantenimiento aunque en tiempo fue despreciada su importancia, es considerado en la actualidad uno de los problemas más riguroso en el desarrollo del software. Muchos investigadores sugieren que el costo de mantenimiento más de la mitad de los costos y recursos globales del desarrollo total del software.

1.9 Calidad del Software

Todas las metodologías y herramientas tienen un único fin que es producir software de gran calidad.

Podemos considerar la calidad del software como:

“La concordancia entre los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

32

Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se sigue ninguna metodología siempre habrá falta de calidad. Existen algunos requisitos implícitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que también pueden implicar una falta de calidad.

Aseguramiento de calidad del software (Software Quality Assurance)

El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfacerá los requisitos dados de calidad. El aseguramiento de calidad del software se diseña para cada aplicación antes de comenzar a desarrollarla y no después.

El aseguramiento de calidad del software está presente en:

Métodos y herramientas de análisis, diseño, programación y prueba. Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del

software. Estrategias de prueba multiescala. Control de la documentación del software y de los cambios realizados. Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de

ellos). Mecanismos de medida (métricas). Registro de auditorias y realización de informes.

1.9.1 Factores de calidad del software

La construcción de software de calidad requiere el cumplimiento de numerosas características. Entre ellas se destacan:

Eficiencia : La eficiencia del software está dada por la capacidad de hacer un buen uso de los recursos que manipula.

Transportabilidad (Portabilidad) : La portabilidad es la facilidad con que un software puede ser transportado sobre diferentes sistemas físicos y lógicos.

Verificabilidad : La verificabilidad es la facilidad de verificación de un software, es la capacidad de soportar los procedimientos de validación y facilitar juegos de pruebas ó ensayos de programas.

Integridad : La integridad es la capacidad de un software de proteger sus propios componentes contra los procesos que no tengan derecho de acceso.

33

Fácil de utilizar : Un software es fácil de utilizar si se puede comunicar con él de manera cómoda.

Corrección : Capacidad de los productos de software de realizar exactamente las tareas definidas en su especificación.

Robustez : Capacidad de los productos de software de funcionar incluso en condiciones anormales.

Extensibilidad : Facilidad que tienen los productos de adaptarse a cambios en su especificación. Para esto es bueno seguir principios de diseño simple y descentralizado.

Reutilización : Capacidad de los productos para ser reutilizados en parte o en su totalidad en nuevas aplicaciones.

Compatibilidad : Facilidad de los productos de ser combinados con otros.

1.10.2 Bibliografía.

Para profundizar los conocimientos adquiridos en este capítulo, puede consultar la siguiente literatura:

Pressman R.: Ingeniería del Software. Un enfoque práctico. Cuarta Edición. Mc Graw Hill. 1997.

Meyer B.: Reusable Software: The Base Object Oriented Component Libraríes, Prentice-Hall, 1995.

[IEEE93] IEEE Estándar Collection: Software Engineering, IEEE Standard 610.12-90, IEEE 1993.

[WAS80] Wasserman A: Principles of Systematics Data Design and Implementation, en Software Design Thecniques (Pressman and Waserman ed.) tercera edicion, IEEE Computer Society Press, 1980, 287-293.

5.2 Bibliografía.

Para profundizar los conocimientos adquiridos en este capítulo, puede consultar la siguiente literatura:

Modelado y diseño orientados a objetos. Metodología OMT . Prentice Hall. 1995Rumbaugh, Jim y otros.

Object-Oriented Modeling and Design. Prentice Hall. 1991.

34

Rumbaugh, Blaha, et. al.

Análisis y Diseño orientado a objetos con aplicaciones. Benjaming Cummings 1994Booch, Grady.

Ingeniería del Software. Un enfoque práctico. Mc Graw Hill. 1997 Cuarta EdiciónRoger Pressman.

www.rational.com

35