Fundamentos de Ingeniería de software · PDF filedesea el cliente, y trabajará...

Fundamentos de Ingeniería de software Este documento contiene información de los conceptos básicos de la Ingeniería del Software para la realización de una aplicación vista como un producto de calidad. 02/04/2011

INTRODUCCIÓN

La unidad está dividida en 7 módulos básicos de los temas relacionados a la producción de

software científico y de calidad. Cada módulo tiene un objetivo a realizar, el contenido del

tema, al final tiene unas actividades obligatorias a realizar en el aula de clases, actividades

sugeridas para hacer en casa, Recursos para ampliar el tema y una autoevaluación como

prueba Sumativa.

Evaluación

Consiste en lo siguiente:

1. Las actividades de sugeridas y auto evaluación corresponden a una nota parcial.

2. La asistencia y actividades obligatorias se toman como tareas.

3. Las actividades sugeridas se toman como notas del parcial 2.

4. La realización del proyecto final.

Calificación Numérica

Parcial 1 25%

Parcial 2 25%

Asistencia y actividades obligatorias 10%

Proyecto final 40%

Total 100%

Fechas importantes

2 abril Módulo 1

9 abril Módulo 2 y 3

16 abril Módulo 4

23 abril Módulo 5

30 abril Módulo 6

07 Mayo Módulo 7

14 Mayo Entrega Proyecto final.

PROYECTO FINAL.

La escuela xyz tiene un crecimiento de matrícula de estudiantes. Solicita una aplicación que

permita insertar los nuevos estudiantes con sus respectivos módulos de consulta,

modificación, eliminación, promoción y reportes de registros de estudiantes para agilizar

los trámites administrativos.

Desarrollo del proyecto.

- Presentar la documentación de análisis y diseño del sistema. (modelo ing. Software).

Puntaje 10%

- Presentar la codificación fuente y ejecutable del sistema. (documentación de línea de

código). Puntaje 10%

- Presentar la estimación o costo del proyecto. 20 %

EL avance del proyecto se supervisará en el aula de clases.

Para recordar

NO pierda de vista que la función del cliente la hace el profesor, usted como gestor del

proyecto presentará todas las semana los prototipos del sistema. Si trabaja constantemente

en su proyecto, se estima que por la tercera o 4 semana de clases ya tiene definido lo que

desea el cliente, y trabajará en el tiempo sub siguiente los tres puntos del desarrollo del

proyecto.

FUNDAMENTOS DE INGENIERIA DE SOFTWARE

MODULO 1

INTRODUCCION OBJETIVO: Comprender que es la ingeniería de software, los diversos modelos del proceso del software y cuando deben utilizarse.

JUSTIFICACION: En la realización de un proyecto es necesario basarnos en los métodos, herramientas y procedimientos, la ingeniería de software está compuesta por estos tres elementos clave.

INTRODUCCION: Se necesita seleccionar el modelo de proceso apropiado que deba aplicarse al proyecto.

1.1 ¿QUE ES LA INGENIERIA DE SOFTWARE?

Es la ciencia que ayuda a elaborar sistemas con el fin de que sea económico, fiable y funcione eficientemente sobre las maquinas reales. La ingeniería de software surge de la ingeniería de sistemas y de hardware. Abarca un conjunto de 3 elementos clave: métodos, herramientas y procedimientos, estos facilitan al gestor a controlar el proceso de desarrollo de software y suministra a los que practique dicha ingeniería las bases para construir software de alta calidad. Los métodos de la ingeniería de software. Suministran el cómo construir técnicamente el software. Los métodos abarcan un amplio espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los requerimientos del sistema y del software, diseño de procedimientos algorítmicos, codificación, prueba y mantenimiento. Los métodos de la ingeniería de software introducen frecuentemente una notación especial orientada al lenguaje o gráfica y a un conjunto de criterios para la calidad del software.

Las herramientas de ingeniería de software. Suministran un soporte automático o semiautomático

para los métodos. Cuando se integran las herramientas de forma que la información creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte del desarrollo del software llamado ingeniería de software asistido por computadora, por mencionar alguna de estas herramientas existen las herramientas CASE.

CASE[(Ingeniería de software asistida por computadora) computer aided software engineering]. Combina del software, hardware y base de datos para crear un entorno de la ingeniería de software. Las herramientas son como voy a aplicar los métodos para tener un desarrollo. Las herramientas de ingeniería de software son los métodos necesarios para desarrollar el sistema.

Los procedimientos de la ingeniería de software. Son la cola que paga a los métodos y

herramientas, facilita un desarrollo racional y oportuno del software de computadoras.

Los procedimientos definen la secuencia en la que se aplican los métodos, las entregas que se requieren y los controles que ayuden asegurar, la calidad y coordinar los cambios y las guías que facilitan a los gestores de software establecer el desarrollo.

Actividades Obligatorias

-Investigue otras 2 definiciones de ingeniería de software. -La ingeniería de software abarca un conjunto de 3 elementos clave, explique cada uno de ellos. Actividades sugeridas -Cree su propia definición de lo que es la ingeniería de software. Recursos para ampliar el tema Págs. 17-18, Ingeniería de software un enfoque práctico, 4a. edición, Roger S. Pressman, Ed. Mc Graw Hill, 1997. Autoevaluación ¿Qué es la ingeniería de software? ¿Para qué son los métodos de la ingeniería de software? ¿Qué son los procedimientos? ¿Qué son las herramientas? ¿Para que nos sirven las herramientas?

1.2 PARADIGMAS

La ingeniería de software esta compuesta por una serie de pasos de abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos.

Gama de paradigmas de la ingeniería de software:

PARADIGMA CICLO DE VIDA DEL SOFTWARE

Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, diseño, codificación, prueba y mantenimiento.

Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.

La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.

Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.

Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.

estructura de datos

arquitectura de software

detalle procedimental

El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.

Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.

Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.

Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.

El ciclo de vida clásico es el mas viejo y más ampliamente usado paradigma en la ingeniería de software. Sin embargo con el paso de unos cuantos años se han producido criticas al paradigma, incluso por seguidores activos que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se presentan algunas veces cuando se aplica este paradigma se encuentran:

1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre ocurre iteraciones y se crea problemas en la aplicación del paradigma.

2. Normalmente es difícil para el cliente establecer explícitamente el principio todos los requerimientos del sistema. El ciclo de vida clásico requiere esto y tiene dificultades para acomodar posibles incertidumbres que puedan existir al comienzo de dichos proyectos.

3. El cliente debe tener paciencia. Una versión funcional del programa no esta disponible hasta las etapas finales del desarrollo del proyecto. Un error importante no detectado hasta que el programa este en funcionamiento puede ser desastroso.

4. Los responsables del desarrollo se retrasan innecesariamente.

PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS

Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.

En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:

Un prototipo en papel que describa la interrelación hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelación; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.

La secuencia de sucesos para el paradigma de construcción de prototipos se muestra en al siguiente figura:

Como todos los métodos de desarrollo de software la construcción de prototipos comienza con la recolección de los requerimientos del sistema. El técnico y el cliente se reúnen y definen los objetivos globales para el software, identifican todos los requerimientos conocidos y perfilan las áreas donde será necesario una mayor definición. Luego se produce un diseño rápido. El diseño rápido se enfoca sobre la representación de los aspectos del software visibles al usuario por ejemplo: métodos de entrada y formatos de salida. El diseño rápido conduce a la construcción de un prototipo. El prototipo es evaluado por el cliente-usuario y se utiliza para refinar los requerimientos del software a desarrollar. Se produce un proceso interactivo en el que prototipo es afinado para que satisfaga las necesidades del cliente al mismo tiempo que facilita al que lo desarrolla una mejor comprensión de todo lo que hay que hacer idealmente, el prototipo sirve como un mecanismo para identificar los requerimientos del software. Si se construye un prototipo que funcione, el realizador intenta hacer uso de fragmentos de programas existentes o aplique herramientas por ejemplo: gestores de informes, gestores de ventanas, etc. Que faciliten la rápida generación de programas que funcione.

CARACTERISTICAS:

Este paradigma ayuda al cliente a brindar requisitos paso a paso. También facilita al programador ir probando algoritmos no explotados con anterioridad, de

los que no tiene seguridad de su eficiencia. Consiste en la creación de prototipos

DESVENTAJAS:

La construcción de prototipos como paradigma para la ingeniería de software puede ser problemático por las siguientes razones:

1. El cliente ve funcionando lo que parece ser una versión del software ignorando que el prototipo se ha hecho con chicle y alambres, ignora que por las prisas hacer que funcione no han considerado los aspectos de calidad y mantenimiento a largo plazo del software.

Cuando se informa al cliente que el producto debe ser reconstruido, este grita horrible y solicita que el producto se le aplique en cuantas mejoras se han necesarias para hacer del prototipo un producto final que funcione. Demasiadas veces el gestor del desarrollo del software sede.

2. El técnico del desarrollo realiza frecuentemente ciertos compromisos de implementación en orden a obtener un prototipo que funcione rápidamente. Puede utilizarse un S.O. o lenguaje de programación inapropiado simplemente porque esta disponible y es conocido. Un algoritmo ineficiente puede implementarse de forma sencilla para demostrar su capacidad; después de pasar un tiempo en el que el técnico esta familiarizado con estas selecciones, olvida las razones por las que eran inapropiadas. La elección menos ideal forma ahora parte integral del sistema.

Aunque se puede presentar problemas, la construcción de prototipos es un paradigma efectivo para la ingeniería de software. La clave de esta es definir desde el comienzo las reglas del juego, esto es que le cliente y el técnico deben de estar de acuerdo en que el prototipo se construya para servir solo como un mecanismo de definición de los requerimientos. Posteriormente ha de ser descartada o al menos una parte y debe construirse el software real con ojos puestos en la calidad y mantenimiento.

PARADIGMA DEL MODELO ESPIRAL

Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las ultimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.

CARACTERISTICAS:

Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos.

Incluye la etapa de análisis de riesgos, no incluida anteriormente. Es ideal para crear productos con diferentes versiones mejoradas como se hace con el

software moderno de microcomputadoras. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de

prototipos. Este es el enfoque más realista actualmente.

El modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.

Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.

Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.

Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.

Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.

VENTAJAS:

El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.

Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.

Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.

Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.

Reduce los riesgos antes de que se conviertan en problemáticos.

Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.

La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representa el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.

PROBLEMAS:

Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable. Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la

evolución

EL MODELO DRA

El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Obviamente la limitación de tiempo impuesto en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.

DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.

No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.

DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.

PARADIGMA DE TÉCNICAS DE CUARTA GENERACION

El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.

Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existen, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.

El paradigma T4G para la ingeniería de software se describe en la siguiente figura:

Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. Idealmente el cliente debe describir los requerimientos y estos debe traducirse directamente en un prototipo operacional pero este no funciona. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo en este momento el dialogo cliente técnico descrito por los otros paradigmas permanecen como una pequeña parte esencial del enfoque T4G. Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, usando un lenguaje de cuarta generación no procedimental (L4G) sin embargo es necesario un mayor esfuerzo para desarrollar una estrategia del diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para grandes proyectos causará las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales.

La implementación usando L4G facilita el que desarrolla al software la descripción de los resultados deseados, los cuales se traducen automáticamente en código fuente para producir dichos resultados. Obviamente debe existir una estructura de datos con información relevante y debe estar rápidamente accesible al L4G.

El ultimo paso de la figura anterior contiene la palabra producto par transformar una implementación T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar todas las otras actividades de transición requeridas en los otros paradigmas de la ingeniería de software. Además del software desarrollado con T4g, debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma expertiva. Los defensores aducen reducciones dramáticas en el tiempo de desarrollo en el software y una mejora significativa en la productividad de la gente que construye el software. Los detractores de este paradigma aducen que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g esta abierta a discusión.

Hay algunos méritos en las razones de cada parte. Aunque es algo difícil separar los hechos de las suposiciones es posible resumir el estado actual de los métodos T4G:

1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.

2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño.

3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.

Para resumir las técnicas de cuarta generación se convertirán en una parte importante en el desarrollo del software durante la siguiente década. Como muestra la siguiente figura la demanda del software continuara creciendo durante el resto del siglo, pero los métodos y paradigmas convencionales contribuirán cada vez menos al desarrollo del mismo.

Las T4G rellenan el hueco que existe hasta que sean practicables los métodos de la IA de la quinta generación.

EL MODELO DE DESARROLLO CONCURRENTE

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:

Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto...La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

La figura siguiente proporciona una representación esquemática de una actividad dentro del modelo de proceso concurrente. La actividad "análisis" se puede encontrar en uno de los estados destacados anteriormente en cualquier momento dado. De forma similar otras actividades se pueden representar de una forma análoga. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicación con el cliente (no mostrada en la figura) ha finalizado su primera interacción y existe en el estado de cambios en espera. La actividad de análisis (que existía en el estado ninguno mientras que comenzaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.

El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparara la actividad de análisis del estado hecho al estado cambios en espera.

El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componente funcional. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y realización. La concurrencia se logra de dos formas (1) las actividades del sistema y de componente ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente; (2) una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las transiciones entre los estados de una actividad.

COMBINACIÓN DE PARADIGMAS

Frecuentemente se describe a los paradigmas de la ingeniería de software tratados en las

secciones anteriores como métodos alternativos, para la ingeniería de software en vez de los métodos complementarios.

En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.

La siguiente figura muestra como pueden combinarse los 3 paradigmas mencionados durante un trabajo de desarrollo del software, en todos los casos el trabajo comienza con la recolección de requerimientos. El método puede seguir el ciclo de vida clásico (ingeniería de sistemas análisis de requerimiento de software) o puede ser la definición menos formal del problema usada en la construcción de un prototipo, independientemente debe producirse la comunicación cliente-realizador del software.

La naturaleza de aplicación dictara la aplicabilidad del método de construcción de prototipos. Si los requerimientos para la función y rendimiento del software están razonablemente bien comprendidos pueden ser aplicables los métodos de especificación recomendados para el ciclo de vida clásico. Por otra parte si la aplicación del software exige una fuerte interacción hombre-maquina o requiere algoritmos no probados o técnicas de control de salidas pueden regresarse a un prototipo. En tales casos puede usarse un lenguaje de cuarta generación para el desarrollo de un prototipo. Una vez que se haya evaluado y refinado el prototipo pueden aplicarse los pasos de diseño e implementación del ciclo de vida clásico para desarrollar el software formalmente.

EL PROCESO Las fases genéricas que caracterizan el proceso de software (definición, desarrollo y mantenimiento) son aplicables a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniería de software que debe aplicarse en el proyecto. El gestor del proyecto debe decidir que método de proceso es el mas adecuado para el proyecto, después debe definir un plan preliminar basado en un conjunto de actividades estructurarles validas para cualquier proyecto. Una vez establecido el plan preliminar, empieza la descomposición del proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades estructurales.

Maduración Del Problema Y El Proceso.

La planificación del proyecto empieza con la maduración del problema y del proceso. Todas las funciones que se deben tratar dentro de un proceso de ingeniería por el equipo de software deben pasar por el conjunto de actividades estructurales que se han definido por una organización de software. Asuma que la organización ha adoptado el siguiente conjunto de actividades estructurales:

-Comunicación con el cliente: tareas requeridas para establecer una comunicación eficiente entre

el desarrollo y el cliente. -Planificación: Tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a el. -Análisis de riesgo: Tareas requeridas para valorar los riesgos técnicos y de gestión. -Ingeniería: Tareas requeridas para construir una o mas representaciones de la aplicación. -Construcción y entrega: Tareas requeridas para construir, probar, instalar y proporcionar asistencia al usuario. (Ejemplo: documentación y entrenamiento).

Evaluación del cliente: Tareas requeridas para obtener la información de la opinión del cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementadas durante la fase de ingeniería e implementadas durante la fase de instalación.

Los miembros del equipo que trabajan en cada función aplicaran todas las actividades estructurales. En esencia, se crea una matriz similar a la que se muestra en la figura. Cada función principal del problema se lista en una columna de la izquierda. Las actividades estructurales se listan en la fila de arriba. Las tareas de trabajo de la ingeniería de software se introducirán en la fila siguiente. El trabajo de gestor del proyecto es estimar los requisitos de recursos para cada celda de la matriz, poner fechas de inicio y finalización para las tareas asociadas con cada celda y los productos a fábricas como consecuencia de cada celda.

Descomposición Del Proceso

Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, la ECP (comunicación con el cliente, planificación, análisis de riesgo, ingeniería, construcción, entrega y evaluación del cliente) puede adaptarse al paradigma. Funcionara para modelos lineales, para modelos interactivos e increméntales, para modelos de evolución e incluso para modelos concurrentes o de ensamblaje de componente. La ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.

La descomposición de trabajo empieza cuando el gestor del proyecto pregunta: "¿cómo vamos a realizar esta actividad ECP?". Por ejemplo, un pequeño proyecto, relativamente simple, requiere las siguientes tareas para la actividad de comunicación con el cliente:

1.- Desarrollar una lista de aspectos que se han de clasificar.

2.- Reunirse con el cliente para resolver los aspectos que se han de clasificar.

3.- Desarrollar conjuntamente una exposición del ámbito del proyecto.

4.- Revisar el alcance del proyecto con todos los implicados.

5.-Modificar el alcance del proyecto cuando se requiera.

Estos acontecimientos pueden ocurrir en un periodo de menos de 48 horas. Representa una descomposición del problema apropiado para proyectos pequeños relativamente sencillos.

Ahora, consideremos un proyecto más complejo que tenga un ámbito mas amplio y un mayor impacto comercial. Un proyecto como ese podría requerir las siguientes tareas para la actividad de comunicación con el cliente:

1. Revisar la petición del cliente. 2. Planificar y programar una reunión formal con el cliente. 3. Realizar una investigación para definir soluciones propuestas y enfoques existentes. 4. Preparar un "documento de trabajo" y una agenda par la reunión formal. 5. Realizar una reunión. 6. Desarrollar conjuntamente mini-especificaciones que reflejan la información, función y

características de comportamiento de software. 7. Revisar todas las mini-especificaciones para comprobar su corrección, su consistencia y

sus ambigüedades. 8. Ensamblar las mini-especificaciones en un documento de alcance del proyecto. 9. Revisar ese documento general con todo lo que pueda afectar. 10. Modificar el documento de alcance del proyecto cuando se requiera.

Ambos proyectos realizan la actividad estructural que denominamos comunicación con el cliente, pero el equipo del primer proyecto lleva a cabo la mitad de tareas de ingeniería del software que el segundo.


¿Cual de los paradigmas de la ingeniería de software sería más útil para las aplicaciones del software?¿Porque?. Proporcione tres ejemplos de técnicas de 4ª generación. Describa el modelo concurrente A medida que vaya hacia afuera del modelo espiral ¿qué puede decir del software que se esta desarrollando? Explique los pasos tradicionales de cualquier modelo. Actividades sugeridas Proporcione cinco ejemplos de desarrollo del software que sean adecuados para construir prototipos. Nombre dos o tres aplicaciones que fueran más difíciles para construir prototipos. ¿Cómo seleccionar el modelo adecuado? Explique como el paradigma ciclo de vida clásico y el de construcción de prototipos pueden acomodarse en el modelo espiral. Recursos para ampliar el tema págs. 21-32, 46-47, Ingeniería de software. Un enfoque práctico, 4a. edición, Roger S. Pressman, Ed. Mc Graw Hill, 1997.

Autoevaluación

1. ¿Cuales son las características del paradigma ciclo de vida clásico? 2. ¿En que consiste el paradigma de construcción de prototipos? 3. ¿Cuales son los pasos a seguir en el paradigma espiral? 4. ¿Cuáles son las desventajas del modelo DRA? 5. ¿Cuál es el paradigma de técnicas de cuarta generación?

MODULO 2

DESARROLLO Y GESTION DE PROYECTOS INFORMATICOS.

Objetivo.

Introducir las técnicas para estimar el costo y el esfuerzo requeridos para la producción de software.

Justificación.

Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad.

Introducción.

Si los proyectos de la ingeniería de software deben desarrollarse estimando el costo y el esfuerzo es esencial una buena planeación

2.1 MÉTRICAS

En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad.

El principio, podría parecer que la necesidad de la medición es algo evidente. Después de todo es lo que nos permite cuantificar y por consiguiente gestionar de forma más efectiva. Pero la realidad puede ser muy deferente. Frecuentemente la medición con lleva una gran controversia y discusión.

1. ¿Cuáles son las métricas apropiadas para el proceso y para el producto? 2. ¿Cómo se deben utilizar los datos que se recopilan? 3. ¿Es bueno usar medidas para comparar gente, procesos o productos?

Estas preguntas y otras tantas docenas de ellas siempre surgen cuando se intenta medir algo que no se ha medido en el pasado.

La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos por mencionar algunos aspectos. Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería del software. Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas.

Hay varias razones para medir un producto.

1. Para indicar la calidad del producto. 2. Para evaluar la productividad de la gente que desarrolla el producto. 3. Par evaluar los beneficios en términos de productividad y de calidad, derivados del uso de

nuevos métodos y herramientas de la ingeniería de software. 4. Para establecer una línea de base para la estimación 5. Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.

Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y medidas indirectas.

Medidas Directas. En el proceso de ingeniería se encuentran el costo, y el esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado periodo de tiempo.

Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc.

MÉTRICAS DEL SOFTWARE.

Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad,

eficiencia.

MÉTRICAS TÉCNICAS: Se centran en lasa características de software pro ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo esta hecho.

MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.

MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseñar.

MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va hará el sistema.

MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura:

La tabla lista cada proyecto del desarrollo del software de los últimos años correspondientes, datos orientados al tamaño de c/u. Refiriéndonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12.1 KLDC (miles de líneas de código) con un esfuerzo de 24 personas mes y un costo de 168 mil dólares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las actividades de la ingeniería de software como son análisis, diseño, codificación y prueba. Otra información del proyecto 222-01 indica que se desarrollaron 365 paginas mientras que se encontraron 29 errores tras entregárselo al cliente, dentro del primer año de utilización también sabemos que trabajaron 3 personas en el desarrollo del proyecto.

En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede desarrollar, para cada proyecto un conjunto de métricas sencillas de productividad y calidad orientadas al tamaño. Se obtienen las siguientes formulas:

Productividad = KLDC/persona-mes

Calidad = errores/KLDC

Documentación = pags. Doc/ KLDC

Costo = $/KLDC

persona-mes es el esfuerzo

MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso

por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa.

Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad del software.

Los puntos de función se calculan rellenando la tabla como se muestra en la siguiente figura:

Calculo de métricas de punto de función.

Se determinan 5 características del ámbito de la información y los cálculos aparecen en la posición apropiada de la tabla. Los valores del ámbito de información están definidos de la siguiente manera.

1. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado.

2. Numero de salida del usuario: se encuentra cada salida que proporciona la usuario información orientada ala aplicación. En este contexto las salidas se refieren a informes, pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe se encuentran por separado.

3. Números de peticiones al usuario: una petición esta definida como una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. Se cuenta cada petición por separado.

4. Numero de archivos: se cuenta cada archivo maestro lógico, o sea una agrupación lógica de datos que puede ser una parte en una gran base de datos o un archivo independiente.

5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir información a otro sistema.

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinación de la complejidad es algo subjetivo.

Para calcular los puntos de función se utiliza la siguiente relación.

PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]

Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.

Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las respuestas a las cuestiones señaladas de la siguiente tabla.

Evaluar cada factor en escala 0 a 5.

Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas de los ámbitos de información han sido determinados empíricamente.

Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de la productividad, calidad y otros productos del software.

Productividad = PF / persona-mes

Calidad = Errores / PF

Costo = Dólares / PF

Documentación = Pags. Doc / PF

La medida de puntos de función se diseño originalmente para ser utilizadas en aplicación de

sistemas de información de gestión. Sin embargo, algunas aplicaciones se les denomina puntos de características.

La medida del punto de característica da cabida a aplicaciones cuya complejidad algoritmica es alta. Las aplicaciones de software de tiempo real de control de procesos y de sistemas que encontrados tienden a tener una complejidad algoritmica alta y por tanto fácilmente tratables por puntos de características.

Para calcular los puntos de características, nuevamente se cuentan y ponderan los valores del ámbito de información, como se describió anteriormente. Además, las métricas de punto de característica tienen en cuenta otra característica del software, los algoritmos.

Un algoritmo se define como un problema de complejidad computacional limitada que se incluye dentro de un determinado programa de computadora. La inversión de una matriz, la decodificación de una cadena de bits o el manejo de una interrupción son todo ellos ejemplos de algoritmos.

Para calcular los puntos de característica, se utiliza la siguiente tabla.

Puntos de característica

Se usa único valor de peso para cada uno de los parámetros de medida y se calcula el valor del punto característica global mediante la ecuación.

PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]

Debe tenerse en cuenta que los puntos de característica y los puntos de función representan lo mismo. "funcionalidad o utilidad" en forma de software.


Métricas orientadas al tamaño

Proyecto Esfuerzo $ KLDC Pag. doc Errores Gente

Farmacia 30 168,500 12,100 378 29 5

Hospital 60 578,300 39,443 921 540 20

Calcular:

a) Productividad = KLDC/esfuerzo

Hopital = ? farmacia = ?

b) Calidad = Errores/KLDC

Hospital = ? Farmacia = ?

c) Costo = $/KLDC

Hospital = ? Farmacia = ?

d) Documentación = Pags. doc/KLDC

Hospital=? Farmacia=?

Métricas orientadas a la función

Se tiene un sistema el cual cuenta con 3 entradas de catalogo productos, proveedores y clientes. Una pantalla de la elaboración de facturas, 4 tipos de reportes proporcionados tanto en pantalla como en papel. Estas representaciones son: factura, lista de inventario, estado de cuenta de los clientes y estado de cuenta con los proveedores. Además la entrada de factura tiene alrededor de 30 peticiones, el sistema genra alrededor de 30 archivos además de estar conectado a un lector óptico y una impresora. Calcula los puntos de función.

Parámetro de medida Cuenta

Factor de peso medio

Numero de entradas al usuario

4 * 4 = 16

Numero de salidas al usuario

8 * 5 = 40

Numero de peticiones al usuario

30 * 4 = 120

Numero de archivos 30 * 10 = 300

Numero de interfaces externas

2 * 7 = 14

Cuenta total = 490

Contestación de las preguntas basada en la complejidad media

1=0; 2=5; 3=3; 4=5; 5=5;

6=5; 7=1; 8=5; 9=2; 10=2;

11=4; 12=0; 13=0; 14=4

Fi =? PF = ? Productividad = ? Calidad = ? Costo = ? Documentación = ?

Actividades sugeridas

o Sugiera tres métricas de calidad y de productividad directas y 3 indirectas para la documentación del software.

o Describa dos métricas utilizadas para medir la productividad de los programadores. o ¿Qué es una metrica indirecta y porque son comunes tales cambios en un trabajo

de metricas de software?

Recursos para ampliar el tema

Págs. 51-61, Ingeniería de software. un enfoque práctico, 4ª edición, Roger S. Pressman, Ed. Mc Graw Hill, 1997.

Autoevaluación

1. ¿Qué son las métricas? 2. ¿Cuáles son las métricas directas? 3. ¿Cuáles son las métricas indirectas? 4. ¿Cuáles son las métricas del software? 5. ¿Cuáles son las métricas orientadas a la función?

2.2 ESTIMACIÓN

Es una pequeña planeación sobre que es lo que va a ser mi proyecto. Una de las actividades cruciales del proceso de gestión del proyecto del software es la planificación. Cuando se planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Pero que pasa si el proyecto es totalmente distinto entonces puede que la experiencia obtenida no sea lo suficiente.

Se han desarrollado varias técnicas de estimación para el desarrollo de software, aunque cada una tiene sus puntos fuertes y sus puntos débiles, todas tienen en común los siguientes atributos.

1. Se han de establecer de antemano el ámbito del proyecto. 2. Como bases para la realización de estimaciones se usan métricas del software de

proyectos pasados. 3. El proyecto se desgloba en partes más pequeñas que se estiman individualmente.


Págs. 45, Ingeniería de software. un enfoque práctico, 3a. edición, Roger S. Pressman, Ed. Mc Graw Hill, 1993.

Autoevaluación

1. ¿Qué es la estimación? 2. ¿Por qué es tan importante?

3 PLANEACIÓN DEL PROYECTO

La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipado problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado. No se analizara la planeación que implica a la estimación de la necesidad de un sistema de software y la habilidad de producir tal sistema, la asignación de prioridad al proceso de su producción.

Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programación, sine embargo estos puntos son validos también para sistemas pequeños.

Panorama. Hace una descripción general del proyecto detalle de la organización del plan y resume el resto del documento.

Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos, fase de diseño de alto nivel, fase de diseño de bajo nivel, etc. Asociada con cada fase debe de haber una fecha que especifique cuando se debe terminar estas fases y una indicación de como se pueden solapar las distintas fases del proyecto.

Plan de organización. Se definen las responsabilidades especificas de los grupos que intervienen en el proyecto.

Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas, procedimientos y responsabilidades para realizar las pruebas del sistema.

Plan de control de modificaciones. Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema.

Plan de documentación. Su función es definir y controlar la documentación asociada con el proyecto.

Plan de capacitación. Se describe la preparación de los programadores que participan en el proyecto y las instrucciones a los usuarios para la utilización del sistema que se les entregue.

Plan de revisión e informes. Se analiza como se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto.

Plan de instalación y operación. Se describe el procedimiento para instalar el sistema en la localidad del usuario.

Plan de recursos y entregas. Se resume los detalles críticos del proyecto como fechas programadas, marcas de logros y todos los artículos que deben entrar bajo contrato.

Indice. Se muestra en donde encontrar las cosas dentro del plan.

Plan de mantenimiento. Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen que dar para futuras versiones del sistema.

ERRORES CLASICOS EN UN PROYECTO INFORMATICO.

1. Mal análisis en los requerimientos. 2. Una mala planeación. 3. No tener una negociación (documento, contrato) con el cliente. 4. No hacer un análisis costo beneficio. 5. Desconocer el ambiente de trabajo de los usuarios. 6. Desconocer los usuarios que trabajan con el sistema. 7. Mala elección de recursos (hardware, software, humanos).


o Explique las técnicas de estimación para el desarrollo del software. o Explique porque se dice que en muchos de los casos las estimaciones se hacen

valiéndose de la experiencia pasada. o Mencione y explique los errores clásicos en un proyecto informático


o Explique porque la estimación debe ajustarse para tomar en cuenta el proyecto, al personal, al producto y a los factores organizaciones.

o Explique brevemente en que consiste la planeación del proyecto.


Pág. 70, Ingeniería de software. un enfoque práctico, 4a. edición, Roger S. Pressman, Ed. Mc Graw Hill, 1997.

Autoevaluación

1. ¿Por qué es importante las planeación del proyecto? 2. ¿En que consiste el plan de fases? 3. Menciona los puntos requeridos por grandes sistemas de programación.

MODULO 3

ANALISIS DE SISTEMAS

Objetivo.

Especificar por completo el problema y el dominio de la aplicación, para que sea posible construir un diseño correcto.

Justificación.

Antes de construir algo complejo, como una casa, un programa de computadora o un sistema hardware-software el constructor debe entender los requisitos y el entorno del mundo real en el cual va a construirse.

Introducción.

Un buen análisis captura las caracteristicas esenciales del problema y llega a ser el marco para el posterior diseño e implementación. El análisis es la comprensión del problema como preparación para el diseño.

3.1 LA INFORMACIÓN COMO UN RECURSO DE LAS ORGANIZACIONES.

A primeros de los años 60, simplemente se automatizaron funciones de negocio que previamente se hacían manualmente. A medida que paso el tiempo, los programas individuales de computadora se combinaron para componer aplicaciones de negocio. Las aplicaciones se agruparon en sistemas de información principales que prestaban sus servicios a áreas de negocio específicas.

La información se ha colocado en un lugar adecuado como recurso principal. Los tomadores de decisiones están comenzando a comprender que la información no es solo un subproducto de la conducción, si no que a la vez alimenta a los negocios y puede ser el factor crítico par la determinación del éxito o fracaso de estos.

Para maximizar la utilidad de información, un negocio la debe manejar correctamente tal como maneja los demás recursos. Los administradores necesitan comprender que hay costos asociados con la producción, distribución, seguridad, almacenamiento y recuperación de toda información. Aunque la información se encuentra a nuestro alrededor esta no es gratis y su uso es estratégico para posicionar la competitividad de un negocio.

El manejo de la información generada por computadora difiere en forma significativa del manejo de datos producidos manualmente. Por lo general, hay mayor cantidad de información generada por computadora a administrar.

INGENIERÍA DE LA INFORMACION.

El objetivo global de la ingeniería de la información es aplicar tecnología de información de la mejor manera que satisfaga las necesidades generales del negocio. Para conseguirlo la ingeniería de la información debe empezar por analizar los objetivos y metas del negocio, después debe definir las necesidades de la información de cada área de negocio y del negocio en su totalidad. Solo después de hacer esto la ingeniería de la información hace la transición al dominio más técnico de la ingeniería de software; el proceso, donde los sistemas de información, aplicaciones y programas son analizados, diseñados y construidos.

El primer paso de la ingeniería de información es la planificación de la estrategia de la información (PEI). Los objetivos generales del PEI son:

Definir los objetivos y metas del negocio que sean estratégico.

Aislar los factores de éxito crítico.

Analizar el impacto de la tecnología y automatización en las metas y objetivos.

Analizar la información existente para determinar su papel en la consecución de las metas y objetivos.

Los términos de objetivos y metas toman un significado especifico en la PEI. Un objetivo es una declaración general de dirección. Las metas define un curso de acción cuantitativo. Los factores críticos de éxito (FCE) pueden estar unidos a un objetivo o a una meta individual. Si se quiere conseguir un objetivo o una meta debe estar presente un FCE.

El análisis del impacto tecnológico examina los objetivos y las metas y proporciona una indicación de aquellas tecnologías que tendrán un impacto directo o indirecto en el éxito de su consecución. El ingeniero de la información pondera las siguientes cuestiones:

¿Cómo es de critica la tecnología para el logra de un objetivo de negocio?

¿Esta disponible la tecnología actualmente?

¿Cómo modificará la tecnología el modo de hacer negocios?

¿Cuáles son los costes directos e indirectos?

¿Cómo debería el negocio adaptar o extender o objetivos y metas para adecuarse a la tecnología?

Después de la PEI (planificación de la estrategia de información) se hace el análisis del área de negocio (AAN). Durante el AAN, nuestro punto de mira se desplaza de la visión global a la visión de dominio. El ingeniero de la información deber describir como se usan y transforman los objetos de datos o conjunto de atributos (descritos durante la PEI y refinados durante el AAN) dentro de cada área de negocio y como las funciones de negocio y los procesos dentro de cada área de negocio transforman estos objetos de datos.

Los objetos de datos definidos durante la PEI se refinan para el uso dentro de cada área de negocio. Por ejemplo, el objeto de datos cliente es empleado por el departamento de ventas. Después de evaluar las necesidades del departamento de ventas, la definición original de cliente se refina aun más para satisfacer las necesidades de ventas.

Objeto: Cliente

Atributos:

Nombre

Nombre de la compañía à objeto: Compañía

Clasificación del empleo y autorización de compra

Dirección de negocio e información de contacto

Interés de producto(s)

Compra(s) anterior(s)

Fecha de último contacto --> registro de contactos

Estado del contacto -- > estado del ultimo contacto

--> Próxima fecha de contacto

--> Naturaleza recomendada de contacto

El atributo nombre de la compañía ha sido modificado para apuntar a otro objeto denominado Compañía. Este objeto no sólo contiene le nombre de la compañía sino también otros atributos que completan la información necesaria de ese objeto de datos.

Actividades obligatorias:

o Explique porque es importante la información. o Mencione y explique los objetivos generales de la planeación estratégica de la

información. o Ha decidido empezar un negocio con envío de órdenes por correo electrónico.

Como quiere llevar su negocio con eficacia, decide hacer algo de ingeniería de información. Empiece por el PEI. Construya un sencillo modelo de empresa que incluya un organigrama, esquemas de funciones y de los procesos de negocio y un modelo de datos en el ámbito del negocio.

o Asumamos que una de las áreas del negocio que ha identificado para el negocio de software por correo (actividad anterior) es el proceso de pedidos por teléfono. Haga un AAN para desarrollar un modelo de datos y diagrama de flujo del proceso detallado para esta área del negocio.

Actividades sugeridas:

o Explique que realiza la ingeniería de la información. o Explique que se hace durante el análisis del área del negocio. o La planeación de la estrategia de la información empieza por la definición de

objetivos y metas. Ponga ejemplos de cada uno de los dominios del negocio.


Pags. 163-166, Ingeniería de software. Un enfoque practico, Roger S. Pressman, 4ª edición, ed. Mc Graw Hill, 1997.

Autoevaluación

1. ¿Cuál es el objetivo de la ingeniería de la información? 2. ¿Cuál es factor critico para la determinación del éxito o fracaso de los

negocios? 3. ¿Qué es un objetivo? 4. ¿Qué es una meta?

3.2 EL PAPEL DEL ANALISTA DE SISTEMAS

El analista de sistemas generalmente valora la manera que funcionan los negocios examinando la entrada, el procesamiento de datos y la salida de información con el propósito de mejorar los procesos organizacionales.

Muchas mejoras involucran mejor apoyo para las funciones de los negocios por medio del uso de sistemas de información computarizados. Esta definición enfatiza un enfoque sistemático y metódico para analizar, y posiblemente mejorar, lo que esta sucediendo con el contexto específico creado por un negocio.

Se requiere que los analistas de sistemas desempeñen muchos paquetes en el curso de su trabajo. Algunos de estos papeles son:

1. Consultores externos para negocios. 2. Experto de soporte dentro de un negocio. 3. Agente de cambio en situaciones tanto internas como externas.

Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional. Los analistas de sistemas requieren habilidades de comunicación que les permitan relacionarse en forma significativa con muchos tipos de gente diariamente, así como habilidades de computación. Para su éxito es necesario que se involucre el usuario final.

Los analistas proceden sistemáticamente. El marco de referencia para su enfoque sistemático es proporcionado por lo que es llamado el ciclo de vida del desarrollo de sistemas (SDLC). Este puede ser dividido en siete fases secuenciales, aunque en realidad las fases están interrelacionadas y frecuentemente se llevan a cabo simultáneamente. Las siete fases son:

1. Identificación de problemas. 2. Oportunidades y objetivos 3. Determinación de los requerimientos de información 4. Análisis de las necesidades de sistemas 5. Diseño del sistema recomendado 6. Desarrollo y documentación del software 7. Prueba y mantenimiento del sistema e implementación del mismo.

Los paquetes de software basados en microcomputadora automatizado para el análisis y diseño de sistemas son llamados herramientas CASE. Las cuatro razones para la adopción de herramientas CASE son:

1. El incremento de la productividad del analista 2. La mejora de la comunicación entre analistas y usuarios 3. La integración de actividades del ciclo de vida y el análisis. 4. La valoración del impacto de los cambios por mantenimiento.

Los analistas también usan enfoque CARE (Reingeniería Asistida por Computadora) para hacer ingeniería inversa y reingeniería de software para extender la vida del software legado.

Un enfoque nuevo y diferente al análisis y diseño de sistemas es el análisis y diseño de sistemas orientados a objetos (O-O). Estas técnicas están basadas en conceptos de programación orientada a objetos en los cuales los objetos, que son creados incluyen no solamente código acerca de los datos sino también instrucciones acerca de las operaciones que se pueden realizar con ellos.

Cuando la situación organizacional lo demanda, el analista puede apartarse del SDLC para intentar una metodología alterna, tal como la elaboración de prototipos, ETHICS, el enfoque de campeón de proyecto, la metodología Soft Systems o Multiview.

COMPRENSIÓN DE LOS ESTILOS, ORGANIZACINES Y SU IMPACTO SOBRE LOS SISTEMAS DE INFORMACION

Hay tres amplios puntos fundamentales de las organizaciones a considerar cuando se analizan y diseñan sistemas de información. Estos son el concepto de la organización. Esos son el concepto de la organización como sistema, los diversos niveles de administración y la cultura organizacional general.

Las organizaciones son sistemas completos compuestos de subsistemas interrelacionados e interdependientes. Además, los sistemas y subsistemas están caracterizados por su ambiente interno, en un continuo que va desde abiertos a cerrados. Un sistema abierto permite el paso libre de recursos (personas, información y materiales) a través de su frontera. Los sistemas cerrados no permiten el libre flujo de entrada o salida.

Los diagramas entidad-relación ayudan a que le analista de sistemas comprenda las entidades y relaciones que comprende el sistema organizacional. Los cuatro tipos diferentes de relaciones en los diagramas E-R son: relación uno a uno, relación uno a muchos, relación muchos a uno y relación muchos a muchos.

Los tres niveles de control administrativo son: operacional, medio y estratégico. El horizonte de tiempo para la toma de decisiones es diferente para cada nivel.

Las culturas y subculturas organizacionales son de terminantemente importantes sobre la manera en que las personas usan la información y los sistemas de información. Apoyando los sistemas de información y los sistemas de información. Apoyando los sistemas de información en el contexto de la organización como un sistema más grande, es posible darse cuenta que numerosos factores son importantes y deben ser tomados en cuenta cuando se determinen los requerimientos de información y se diseña e implementa los sistemas de información.

DETERMINACIÓN DE LA FACTIBILIDAD Y EL MANEJO DE LAS ACTIVIDADES DE ANÁLISIS Y DISEÑO

Los cuatro puntos fundamentales del proyecto que el analista de sistemas debe manejar son:

1. Iniciación del proyecto 2. Determinación de la factibilidad del proyecto 3. Calendarización del proyecto 4. Administración de los miembros del equipo del análisis de sistema.

Los proyectos pueden ser solicitados por muchas personas diferentes dentro del negocio o por los mismos analistas de sistema.

La selección de un proyecto es una decisión difícil, debido a que serán solicitados más proyectos de los que pueden ser hechos. Cinco criterios importantes para la selección de proyectos son:

1. Que el proyecto solicitado este respaldado por la administración. 2. Que tenga el tiempo adecuado para la asignación de recursos. 3. Que mueva al negocio hacia la obtención de sus objetivos. 4. Que sea practicable. 5. Que sea lo suficientemente importante para ser considerado en vez de otros

proyectos posibles.

Si un proyecto solicitado satisface estos criterios, entonces puede ser elaborado un estudio de la factibilidad de sus méritos operacionales, técnicos y económicos. Por medio del estudio de factibilidad los analistas de sistemas recopilan datos que permiten a la administración decidir si continúan con un estudio de sistema completo.

La planeación del proyecto incluye la estimación del tiempo requerido por cada una de las actividades del analista, su calendarización y la agilización de ellas, si es necesario para asegurar que un proyecto sea terminado a tiempo. Una técnica de que dispone el analista de sistemas para la calendarización de tareas es la gráfica de Gantt, que despliega actividades en forma de barras en una gráfica.

La calendarización de proyectos basada en computadora, usando microcomputadoras, es ahora práctica común, debido principalmente al uso de interfaces de usuario gráficas. Adicionalmente. Se pueden usar los administradores de información personales (PIM) por los analistas para planear, crear deposito de números telefónicos y de fax y hasta para ejecutar otros programas.

Una segunda técnica, llamada PERT (evaluación de programas y técnicas de revisión), despliega las actividades como flechas en una red. El PERT ayuda a que el analista determine la ruta crítica y el tiempo de holgura, que es la información requerida para el control efectivo del proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duración total del proyecto identificación y agilizando las actividades principales.

Una vez que un proyecto ha sido juzgado factible, el analista de sistemas debe administrar a los miembros del equipo, sus actividades, tiempo y recursos. La mayor parte de esto se logra mediante la comunicación con los miembros del equipo. Los equipos están constantemente buscando un balance entre el trabajar sobre las tareas y el mantener las relaciones con el equipo. Deben ser solucionadas las tensiones que suceden al intentar lograr este balance. Frecuentemente emergen dos líderes en un equipo, un líder de tarea y un líder socioemocional. Los miembros deben valorar periódicamente las normas del equipo para asegurarse de que sean funcionales en vez de disfuncionales para el logro de los objetivos del equipo.

Es importante que le equipo de análisis de sistemas ponga objetivos de productividad razonables para las salidas tangibles y las actividades del proceso. Las fallas del proyecto pueden ser evitadas, por lo general, examinando las motivaciones de los proyectos solicitados, así como los motivos del equipo para recomendar o evitar un proyecto particular.


o Describa cuales son las habilidades del analista de sistemas. o Mencione las siete fases secuenciales. o Explique cada una de los tres puntos fundamentales de las organizaciones a

considerar cuando se analizan y diseñan sistemas de información.


o ¿Cuáles son las cuatro razones para la adopción de las herramientas CASE? o Explique en que consiste la técnica PERT. o ¿Cómo se determina la factibilidad del proyecto?

Recursos para ampliar el tema:

Pags. 5-7, Análisis y diseño de sistemas, Kendall & Kendall, 3ª edición, ed. Pearson educación, 1997.

Autoevaluación

1. ¿Quién es el analista de sistemas? 2. ¿Cuáles son algunos de los papeles del analista de sistemas?

3. Explique cual es la principal habilidad del analista de sistemas

3.3 ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN

3.3.1 TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN

Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación

existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas.

E N T R E V I S T A

Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionaran datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos.

Recabar datos mediante la entrevista.

La entrevista es una forma de conversación, ¡no interrogación! Al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre es sistema los analistas pueden conocerlos datos que no están disponibles en ninguna otra forma.

En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son importantes. La información cualitativa esta relacionada con opiniones, políticas y descripciones cuantitativas trata con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de información cualitativa; los otros métodos tienden a ser mas útiles en la recabación de datos cuantitativos.

Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo es más fácil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios.

Determinación del tipo de entrevista.

La estructura de las entrevistas varía. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de preguntas sin estructura, con una sección de preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos más específicos sobre la aplicación o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores.

Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas las personas que responden se basan en un mismo conjunto de posibles respuestas.

La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. De

cualquier manera, el mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para preguntas cerradas.

Dado que un numero de personas se seleccionara para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan

La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así, los analistas que estudian ala administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacén; también entrevistaran a los agentes más importantes.

Realización de la entrevista.

La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista específica como de las preguntas por realizar a una persona determinada.

El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un analista que trabaja en la aplicación enfocada a la reducción de errores probablemente no tendría éxito si llegar a una oficina de gerencia de nivel medio con la presentación equivocada, por ejemplo, si dijera, "hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. O la introducción: "Estamos aquí para resolver su problema", es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo.

A través de la entrevista, los analistas deben preguntarse así mismos las siguientes interrogantes:

1. ¿Qué es lo que me esta diciendo la persona? 2. ¿Por qué me lo esta diciendo a mí? 3. ¿Qué se esta olvidando? 4. ¿Qué espera esta persona que haga yo?

Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán mas conocimientos no solamente de la información adquirida sino también de su importancia.

C U E S T I O N A R I O .

Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.

Recabación de datos mediante cuestionarios

Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran número de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios.

También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede realizarse con un mayor numero de individuos, es muy rara una respuesta total. Puede necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se encontraran en una proporción entre el 25 o 35%, que es lo más común.

Selección de formas para cuestionarios.

El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. También es importante el formato y contenido de las preguntas en la recopilación de hechos significativos.

Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de sistemas.

Cuestionarios abiertos.

Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y mejorarse el proceso de verificación de crédito para los clientes?

Cuestionarios cerrados.

El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma de opinión sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario

Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender por parte de los interrogados.

Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es necesario, antes de que imprima una forma final y se distribuya.

Selección de quienes recibirán el cuestionario

Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto también es desgastante y cara.

O B S E R V A C I O N

¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de otra forma.

Recopilación de datos mediante la observación

Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las actividades del sistema. Entrevistar personal, ya sea directamente o a través de cuestionarios,

también le ayuda y le dice algo más. Ninguno de los dos métodos da una información completa; por ejemplo, leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura.

La observación proporciona información de primera mano en relación con la forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan las tareas y si ocurren los pasos específicos como se pre-establecieron, pueden contestarse rápidamente si se observan las operaciones.

Cuando observar

La observación es muy útil cuando el analista necesita ver de primera mano como se manejan los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y como guiar su significado, también requiere de experiencia. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades; también están alertas para detectar documentos o registros que no se utilizan.

M U E S T R E O

Con frecuencia, en muchas empresas la información ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no esta familiarizado. Muchos tipos de registros e informes son accesibles si el analista sabe donde buscar. En la revisión de registros, los analistas examinan datos y descripciones que ya están escritos o registrados y en relación con el sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como presentación del analista, si se realiza al iniciar el estudio, o como un termino de comparación de lo que sucede en el departamento con lo que los registros presentan como lo que debería suceder.

Recopilación de datos por medio de la inspección de registros.

El termino "registro" se refiere a los manuales escritos sobre políticas, regulaciones y procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existentes, o sistemas de información que entran dentro del área de investigación, también proporcionan una visión sobre la forma en la que el negocio debería conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como cantidad de transacciones o capacidad de almacenamiento de datos) y características de diseño (controles y verificación del procesamiento).

Los registros permiten que los analistas se familiaricen con algunas operaciones, oficinas de la compañía y relaciones formales a las que debe darse apoyo. No obstante, no muestran como producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar datos estudiados en esta sección son más eficaces para proporcionar al analista este tipo de información.

Selección de los registros para revisión

En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para señalar los procedimientos existentes. Los diagramas de organización muestran como las diferentes unidades deberían relacionarse con otras; pero muchas no reflejan las operaciones actuales.


o Explique brevemente la realización de la entrevista o Liste cuatro situaciones que hagan adecuado el uso de cuestionarios.

o ¿Cómo debe ser la selección de quien recibirá el cuestionario? o Defina lo que significa muestreo


o Liste tres razones sobre el porqué la observación es útil para el analista de sistemas en la organización

o Explique brevemente la fase de muestreo. o ¿Qué tipos de información deben ser buscados en las entrevistas?


Pags. 79-82, 109-123, 147-163, 175-181, Análisis y diseño de sistemas, Kendall & Kendall, 3ª edición, ed. Pearson educación, 1997.

Autoevaluación

1. ¿Qué es la entrevista? ¿Para que sirven los comentarios? ¿En que momento es útil observar? ¿Qué es el muestreo o para que sirve?

PROTOTIPOS

El análisis hay que hacerlo independientemente del paradigma que se aplique. En algunos casos es posible aplicar los principios operativos del análisis y obtener un modelo del software del que se pueda desarrollar un diseño. En otras ocasiones se realizan recopilaciones de requisitos u otras técnicas 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.

SELECCIONE EL ENFOQUE DE CREACIÓN DE PROTOTIPOS

El paradigma de creación de prototipos puede ser cerrado o abierto. Al enfoque cerrado se denomina a menudo prototipo desechable. Este prototipo sirve como una basta demostración de los requisitos. Después se desecha y se hace una ingeniería de software con un paradigma diferente. Un enfoque abierto denominado prototipo evolutivo, emplea el prototipo como primera evaluación del sistema terminado.

Antes de poder elegir un enfoque abierto cerrado, es necesario determinar si se puede crear un prototipo como primera evaluación del sistema terminado.

Se pueden definir varios factores candidatos para la creación de prototipos:

área de aplicación , complejidad , características del cliente, características del proyecto

En general cualquier aplicación que cree pantallas visuales dinámicas, interactue intensamente con el ser humano o demande algoritmos o procesamiento de combinaciones que deba de manera progresiva, es un buen candidato para la creación de prototipos. Pero sin embargo estas áreas de aplicación deben ponderarse con la complejidad de la aplicación. Si una aplicación candidata va a requerir el desarrollo de docenas de miles de líneas de código antes de poder realizar cualquier función demostrable, es probable que sea demasiado compleja para la creación de un prototipo.

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. 2. El cliente pueda tomar decisiones inmediatas sobre los requisitos.

MÉTODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS.

Técnicas de cuarta generación. Estas comprenden una amplia gama de lenguajes de consulta y de otros lenguajes no procedimentales de muy alto nivel. Como las técnicas de cuarta generación permiten al ingeniero del software generar código ejecutable rápidamente son ideales para la creación rápida de prototipos.

Componente de software reutilizables. El ensamblar mas que el construir, es un prototipo mediante software existente. Un componente de software puede ser una estructura de datos o un componente arquitectónico. En pocas palabras un software existente que cumpla con los requisitos del cliente.

Especificaciones formales y entornos para prototipos. Durante las pasadas dos décadas, se han desarrollado varios lenguajes formales de especificación y herramientas como sustitutos de las técnicas de especificación con lenguaje natural.

Hoy en día los desarrolladores de estos lenguajes formales están desarrollando entornos interactivos que:

1. Permitan al analista crear interactivamente una especificación basada en lenguaje de un sistema o software.

2. Invoque herramientas automáticas que traducen la especificación basada en el lenguaje de código ejecutable.

3. Permitan al cliente usar el código ejecutable del producto para refinar los requisitos formales.

Métodos y herramientas para el desarrollo de los prototipos, para la selección de un enfoque apropiado de creación de prototipo.


o ¿Cuáles tipos de información está buscando el analista por medio de la elaboración de prototipos?

o Liste las ventajas y desventajas del uso de prototipos o Dé un ejemplo de un prototipo que sea un "primer modelo a escala completa"


o Liste cuatro lineamientos que debe observar el analista en el desarrollo de prototipos

o ¿Cuáles son los criterios para decidir si un sistema debe tener un prototipo o Defina lo que significa un prototipo que es un modelo con algunas pero no todas,

las características esenciales.


o Págs. 192-194, Ingeniería de software. un enfoque práctico,4a. edición, Roger S. Pressman, ed. Mc Graw Hill, 1997

o Págs. 197-208, Análisis y Diseño de sistemas, 3a. edición, Kendall & Kendall, ed. Prentice Hall, 1997

Autoevaluación:

1. ¿Cuáles son los métodos y herramientas para el desarrollo de prototipos? 2. ¿Cuál es el prototipo desechable? 3. ¿Qué es un prototipo? 4. ¿Cuáles son los factores candidatos para la creación de prototipos?

3.4 ANÁLISIS ORIENTADO A OBJETOS

El análisis orientado a objetos esta basado en un modelo de cinco capas:

1. Capa clase/objeto. 2. Capa de estructura. 3. Capa de atributos. 4. Capa de servicios 5. Capa de tema.

La figura ilustra como se entrelazan estas cinco capas.

1. Capa Clase/Objeto. Esta capa indica las clases y objetos. 2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos, tales

como las relaciones uno a muchos y la herencia. 3. Capa de Atributos. Esta capa detalla los atributos de las clases.

4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto (servicios y métodos).

5. Capa de Tema. Esta capa divide el diseño en unidades de implementación o asignaciones de equipos.

Análisis y clases de objetos.

Objeto: es una abstracción de algo en un dominio de un problema que refleja las capacidades de un sistema para llevar información acerca de ello, interactuar con ello a ambas cosas.

Es una representación en computadora de alguna cosa o evento del mundo real. Pueden tener tanto atributos y comportamientos.

Clase. Es una categoría de objetos similares. Los objetos se agrupan en clases. Una clase define el conjunto de atributos y comportamientos compartidos que se encuentran a cada objeto de la clase.

Clase y objeto. Un término que se refiere tanto a clase como a los objetos que ocurren en la clase.

Hay cinco tipos generales de objetos que pueden descubrirse durante el análisis. Los objetos a veces representan cosas tangibles como vehículos, dispositivos y libros. Algunas veces los objetos representan papeles actuados por personas u organizaciones. Los objetos también pueden ser derivados de incidentes o eventos. Otros objetos pueden indicar interacciones tales como una venta o un matrimonio. Las interacciones tienen una cualidad de transacción o contrato. Los objetos también pueden detallar especificaciones. Las especificaciones tienen estándares o una cualidad de definición y, por lo general, implican que otros objetos representaran ocurrencias de cosas tangibles.

Las clases son representadas por cuadros rectangulares redondeados (bubtángulos) divididos en tres partes. El nombre de la clase se muestra en la división superior del cuadro. Las otras dos divisiones se usan para las capas de atributo y servicio. Cuando una clase aparece sin objetos, puede ser solamente una clase base, debido a que la única razón para tal clase "sin objetos" es que sea un medio para agrupar atributos y servicios que serán heredados por varias otras clases.

Los objetos que tienen ocurrencia de una clase son representados por un cuadro sombreados rodeados por la clase. Debido a que los objetos tiene ocurrencias de una clase.

Criterios que podemos usar para que nos ayuden a determinar si se justifica una nueva clase de objetos:

1. Hay una necesidad de recordar el objeto. Esto es, el objeto puede ser descrito en un sentido definido y sus atributos son relevantes para el problema.

2. Hay una necesidad de determinados comportamientos del objeto. Esto es, aunque un objeto no tenga atributos, hay servicios que debe proporcionar o estados de objeto que deben ser llamados.

3. Usualmente un objeto tendrá varios atributos. Los objetos que tienen solamente uno o dos atributos sugieren diseños sobre analizados.

4. Usualmente una clase tendrá más de una instancia de objeto, a menos de que sea una clase base.

5. Usualmente los atributos tendrán siempre un valor significativo para cada objeto de la clase. Los objetos que producen valor NULO para un atributo, o para los que no es aplicable un atributo, por lo general implican una estructura generalización-especificación.

6. Usualmente los servicios siempre se comportarán en la misma forma para todos los objetos de la clase. Los servicios que varían dramáticamente para algunos objetos de una clase o que regresan sin realizar acción para algunos objetos también sugieren una estructura generalización-especificación.

7. Los objetos deben implementar requerimientos que son derivados del problema y no de la tecnología de solución. La parte de análisis del proyecto orientado a objetos no debe llegar a ser dependiente de una tecnología de implementación particular, tal como un sistema de computadora especifico o un lenguaje de programación especifico. Los objetos que atienden tales detalles técnicos no deben aparecer sino hasta muy tarde en la etapa de diseño. Los objetos dependientes de la tecnología sugieren que el proceso de análisis tiene fallas.

8. Los objetos no deben duplicar atributos o servicios que pueden ser derivados de otros objetos del sistema. Por ejemplo, un objeto que guarda la edad de un empleado es superfluo cuando existe un objeto de empleado separado que conserva el atributo fecha de nacimiento. El objeto edad puede ser eliminado por un servicio edad que es componente del objeto empleado.


o Explique las cinco capas en las que esta basado el diseño orientado a objetos o ¿Cuáles son los cinco tipos generales de objetos? o ¿Cómo puede decidirse si una clase ha tenido ocurrencia de objetos?


o Explique los ocho criterios usados para determinar si se justifica una nueva clase o Describa la diferencia entre una clase y un objeto


o Págs. 864-866, Análisis y diseño de sistemas, 3a. edición, Kendall & Kendall, ed. Prentice Hall, 1997

Autoevaluación:

1. ¿Cuáles son las cinco capas en las que está basado el diseño orientado a objetos? 2. Nombra tres criterios para usados para determinar si se justifica una nueva clase 3. ¿Qué es una clase? 4. ¿Qué es un objeto?

3.4.1 MODELO ESTATICO (ESTRUCTURADO)

MODELO DE OBJETOS

Conceptos y Principios Orientados a Objetos.

El enfoque orientado a objetos no es nuevo. Por primera vez fue propuesto a finales de los años 60, pero como muchas cosas en la vida, ha tenido que esperar casi 20 años para ser retomado con la fuerza que tiene actualmente. A diferencia del enfoque estructurado, en el orientado a objetos debemos centrarnos en caracterizar los objetos reales del mundo tal y como ellos son, concibiéndolos de manera natural, con sus características o propiedades y sus operaciones o métodos; y no en la división de estos en estructuras abstractas que particionan todas las características de esos objetos, además de separar de su caracterización las operaciones que incidían sobre los mismos.

Pero hay dos cuestiones básicas que hacen que el enfoque orientado a objetos sea más útil en los momentos actuales:

La reutilización de componentes de software ya creados con anterioridad (objetos que pueden ser usados en diferentes aplicaciones y que se almacenan en bibliotecas de clase).

La facilidad de mantenimiento por ser el Software orientado a objetos de una estructura descompuesta.

El paradigma orientado a objetos durante mucho tiempo se ha identificado con el uso de lenguajes orientado a objetos (Ada95, C++, Delphi, Eiffel, Smalltalk) pero desde hace unos años se trabaja para establecer principios y fundamentos más sólidos en el desarrollo de SW orientado a objetos, pasando por el establecimiento de análisis orientado a objetos, diseño orientado a objetos, SGBDOO, y CASE orientado a objetos.

La Ingeniería de software también está evolucionando para adaptarse al paradigma orientado a objetos. Los principios básicos de la ingeniería des software mencionados antes deben ser adaptados a este nuevo enfoque, pero hay cosas que nos sirven. Por ejemplo si hablamos de un paradigma o ciclo de vida del software, deberíamos pensar en un enfoque evolutivo, pues el software orientado a objetos se caracteriza por su evolución.

Conceptos de la orientación a objetos.

Es evidente que el concepto básico de la orientación a objetos es el objeto, pero para ello debemos precisar primero porque orientado a objetos. Un objeto puede ser algo tan trivial como una silla o una mesa, pero en el mundo hay infinidad de objetos de ese tipo y las declaraciones de atributos y operaciones para cada uno sería muy difícil y desgastante. La verdadera esencia de la orientación a objetos está en la estructuración de una jerarquía de clases y esto trae consigo otros conceptos que siguen. Por otra parte los objetos deben comunicarse unos con otros. Es por ello que Coad y Yourdon definieron la orientación a objetos así:

Orientado a objetos = Objetos + Clasificación + Herencia + Comunicación.

Clases y objetos.

Un modelo orientado a objetos de SW debe exhibir abstracciones de datos y procedimientos que conduzcan a una modularidad eficaz. Una clase es un concepto orientado a objetos que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y el comportamiento de alguna entidad del mundo real.

Una clase es una descripción generalizada que describe una colección de objetos similares. Por definición, todos los objetos que existen dentro de una clase heredan sus atributos y operaciones. De este concepto se derivan cosas como:

Una superclase es una colección de clases.

Una subclase es una instancia de una clase.

Es interesante sin embargo la notación de Taylor sobre una clase, donde queda destacado de forma relevante que la clase encapsula las abstracciones de datos (atributos) dentro de una muralla de abstracciones procedimentales (operaciones), a través de la cual hay que pasar para poder acceder a los datos. De esta forma queda representado de alguna manera el concepto de ocultación de la información. También favorece el concepto de alta cohesión entre los métodos y los pocos datos que estos manipulan, mientras que se presupone también, el acople de la clase con otros elementos del sistema a través de la comunicación vía métodos.

Para todas las cosas orientadas a objetos, el marco de referencia conceptual es el modelo de objetos que incluye cuatro elementos fundamentales: abstracción, encapsulamiento, modularidad y jerarquía; así como tres elementos secundarios: tipos, concurrencia y persistencia.

Una abstracción denota las características esenciales de un objeto que lo distinguen de todos los demás tipos de objetos y proporciona así fronteras conceptuales nítidamente definidas respecto a la perspectiva del observador.

El encapsulamiento es el proceso de almacenar en un mismo compartimento los elementos de una abstracción que constituyen su estructura y su comportamiento; sirve para separar la interfaz contractual de una abstracción y su implantación.

La modularidad es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados.

La jerarquía es una clasificación u ordenación de abstracciones.

Los tipos son la puesta en vigor de una clase de los objetos, de modo que los objetos de tipos distintos no pueden intercambiarse o, como mucho, pueden intercambiarse sólo de formas muy restringidas.

La concurrencia es la propiedad que distingue un objeto activo de uno que no está activo.

La persistencia es la propiedad de un objeto por la que su existencia trasciende el tiempo, el espacio, o ambos.

Atributos.

Los atributos son las características estables que identifican claramente a los objetos y clases de objetos de la vida real. Se puede decir que una característica puede verse como una relación binaria entre una clase y cierto dominio donde quedan definidos los posibles valores que puede tomar esa característica.

Ejemplo: Clase: carro, atributo: color, dominio del atributo: {blanco, rojo, verde, ...}

Operaciones.

Lo característico de la programación orientada a objetos está en que las clases y objetos encapsulan dentro de sí no solo atributos, sino también las operaciones (métodos o servicios) que se implementan para que este objeto reaccione ante un estímulo.

Las operaciones pueden ser vistas como módulos en el sentido convencional y son algoritmos de procesamiento de los datos contenidos en esa clase.

Mensajes.

Los mensajes son el medio a través del cual los objetos interactúan, o sea un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operación.

El pase de mensajes mantiene comunicados a los objetos de un sistema orientado a objetos. Los mensajes proporcionan una visión interna del comportamiento de objetos individuales y del sistema orientado a objetos como un todo.

Encapsulamiento, herencia y polimorfismo.

Estos son tres conceptos clásicos dentro de la orientación a objetos.

Las clases y los objetos derivados de ellas "encapsulan" los datos y las operaciones que trabajan sobre estas en un único paquete. Esto posibilita que:

Los detalles de implementación interna de los datos y operaciones están ocultos al mundo exterior (ocultamiento de la información). Esto reduce la propagación de efectos colaterales cuando ocurren cambios.

Las estructuras de datos y las operaciones que las manipulan están mezcladas en una simple entidad: clases. Esto facilita la reutilización de componentes.

Las interfaces entre objetos encapsulados están simplificadas. Un objeto que envía un mensaje no se tiene que preocupar de los detalles de estructuras de datos internas en el objeto receptor. Esto simplifica la interacción y el acoplamiento tiende a reducirse.

La herencia es un mecanismo que posibilita la reutilización de componentes existentes (como superclase) y reduce el trabajo de creación nuevo. También da la posibilidad de propagar rápidamente por todo el sistema los cambios realizados en niveles superiores de la jerarquía de clases. Por otra parte es posible añadir nuevos atributos y operaciones a las subclases dentro de la jerarquía. Para crear una nueva clase el ingeniero del software puede:

Diseñar y crear una clase desde cero (no usa herencia).

Rastrear la jerarquía de clases para localizar una clase que tenga la mayoría de los atributos y operaciones que necesita la nueva clase, añadiéndosele a la misma los elementos nuevos necesarios.

Reestructurar la jerarquía de clases para que los atributos y operaciones necesarias puedan ser heredadas por la nueva clase.

Sobrescribir las características de una clase existente e implementar versiones privadas de atributos y operaciones para la nueva clase.

A veces la reestructuración de la jerarquía puede ser más difícil y puede ser entonces necesario heredar de una clase que tiene alguna característica que no necesite la nueva clase. En ese caso se aplica la "anulación" de esa característica, haciendo que la herencia no sea transitiva como señala Ivar Jacobson en su metodología OOSE.

En otras ocasiones sucede que es necesario heredar algunos atributos y operaciones de una clase y otros de otra clase. Esto se conoce como "herencia múltiple" y es un concepto muy controvertido pues se sale de la jerarquía normal de clases. Al respecto hay una serie de recomendaciones dadas por James Rumbaugh en su libro "Modelado y Diseño Orientado a Objetos. Metodología OMT"

El polimorfismo es una característica que reduce en gran medida el esfuerzo necesario para extender un sistema orientado a objetos. Se fundamenta en una interpretación, o mejor en una implementación específica de una operación de una clase, de forma diferente en algunas de sus subclases u objetos, de manera que estos puedan "privatizar" esa operación y no haya necesidad de redefinirla para toda la jerarquía o prever las diferentes variantes en la clase. Esto reduce el acoplamiento entre objetos, haciendo a cada uno más independiente.

Identificación de los elementos de un modelo de objetos.

Identificación de clases y objetos.

Los objetos pueden ser:

Entidades externas (otros sistemas, dispositivos, personas) que producen o consumen información a usar por un sistema computacional.

Cosas (informes, presentaciones, cartas, señales) que son parte del dominio de información del problema.

Ocurrencias o eventos (una trasferencia de propiedad, aniversario) que ocurren dentro del contexto de la operación del sistema.

Papeles o roles (director, ingeniero, etc.) desempeñados por personas que interactuan con el sistema.

Unidades organizacionales (división, grupo, equipo) que son relevantes en una aplicación.

Lugares (planta de producción o muelle) que establece el contexto del problema y la función general del sistema.

Estructuras (sensores, vehículos, computadoras) que definen una clase de objetos, o clases relacionales con objetos.

Coad y Yourdon sugieren las características de selección de objetos potenciales para incluirlos en el modelo de análisis:

Información retenida: el objeto potencial será de utilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funcione.

Servicios necesarios: el objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de los atributos.

Atributos múltiples: durante el análisis de requisitos se debe centrar la atención en la información principal (un objeto con un solo atributo, puede en efecto, ser útil durante el diseño, pero seguramente será mejor representado como un atributo dentro de otro objeto durante las actividades de análisis).

Atributos comunes: puede definirse un conjunto de atributos del objeto potencial, aplicables a todas las ocurrencias del objeto.

Operaciones comunes: puede definirse un conjunto de operaciones del objeto potencial, aplicables a todas las ocurrencias del objeto.

Requisitos esenciales: entidades externas que producen o consumen información esencial del sistema.

Especificación de atributos.

Los atributos describen un objeto que ha sido seleccionado para ser incluido en el modelo de análisis.

Para desarrollar un conjunto significativo de atributos para un objeto, el analista puede estudiar de nuevo la descripción del ámbito y el alcance para el problema y seleccionar aquellos elementos que pertenecen al objeto.

Definición de operaciones.

Las operaciones definen el comportamiento de un objeto y cambian de alguna forma los atributos del objeto. Por tanto, una operación debe conocer la naturaleza de los atributos de los objetos y debe ser implementada de manera que permita manipular las estructuras de datos, derivadas de dichos atributos. Existen:

Operaciones que manipulan de alguna forma datos.

Operaciones que realizan algún cálculo

Operaciones que monitorizan un objeto frente a la ocurrencia de un suceso de control.

Gestión de proyectos de software orientado a objetos.

Como ya se analizó en clases anteriores, la gestión de proyectos actual puede subdividirse en las siguientes actividades:

Establecimiento de un marco de proceso común para el proyecto.

Uso del marco y de métricas históricas para desarrollar estimaciones de esfuerzo y tiempo.

Especificación de productos de trabajo y avances que permitirán la medición del progreso.

Definición de puntos de comprobación para asegurar la calidad y el control.

Gestión de cambios que ocurren invariablemente al progresar el proyecto.

Seguimiento, monitorización y control del progreso.

Se analizarán cada una de ellas a continuación.

Marco de proceso común para orientado a objetos.

El marco de proceso común para orientado a objetos siempre es adaptable, para que siempre cumpla con las necesidades individuales del equipo de proyecto. Aquí se define el enfoque organizativo para el desarrollo y mantenimiento del SW, o sea se identifica el paradigma de ingeniería de software, así como las tareas, hitos y entregas requeridos; también se especifica el grado de rigor con que se enfocan los diferentes tipos de proyectos.

Ed Berard y Grady Booch proponen el uso de un modelo recursivo/paralelo para el desarrollo de SW orientado a objetos. Ese modelo funciona así:

Realizar los análisis suficientes para aislar las clases de problemas y las conexiones más importantes.

Realizar un pequeño diseño para determinar si las clases y conexiones pueden ser implementadas de manera práctica.

Extraer objetos reutilizables de bibliotecas, para construir un prototipo previo.

Conducir algunas pruebas para descubrir errores en el prototipo.

Obtención de la realimentación del cliente sobre el prototipo.

Modificar el modelo de análisis basándose en lo que se ha aprendido del prototipo, de la realización del diseño y de la realimentación obtenida del cliente.

Refinar el diseño para acomodar sus cambios.

Construcción de objetos especiales (no disponibles en bibliotecas).

Ensamblar el nuevo prototipo usando objetos de la biblioteca y los objetos que se crearon nuevos.

Realizar pruebas para descubrir errores en el prototipo.

Obtención de la realimentación del cliente sobre el prototipo.

Este enfoque continúa hasta que el prototipo evoluciona hacia una aplicación productiva.

Un poco más concretamente el modelo pudiera definirse así:

Descomposición sistemática del problema en componentes altamente independientes.

Aplicar de nuevo el proceso de descomposición a cada una de las componentes independientes para, a su vez, descomponerlas (parte recursiva).

Conducción de este proceso de replicar la descomposición de forma concurrente sobre todas las componentes (parte paralela).

Continuar este proceso hasta cumplir los criterios de completamiento.

Métricas y estimación de proyectos orientado a objetos.

Las estimaciones realizadas a partir de LCF tienen poco sentido en proyectos orientado a objetos debido a que el objetivo fundamental es la reutilización. Las estimaciones a partir de PF pueden usarse de manera efectiva, pues los elementos del dominio de la información requeridos se pueden determinar a partir del planteamiento del problema, solo que la medida de PF no provee una granularidad suficiente para ajustes de planificación y esfuerzo a realizar, lo cual es necesario si iteramos en un paradigma recursivo/paralelo.

Lorenz y Kidd sugieren el siguiente conjunto de métricas para proyectos:

Número de guiones de escenario: un guión de escenario es una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación. Cada guión se organiza en triplas de la forma: {iniciador, acción, participante}. El número de guiones de actuación está determinado al tamaño de la aplicación y al número de casos de prueba que se deben desarrollar para ejercitar el sistema una vez concluido.

Número de clases claves: las clases clave son las componentes altamente independientes definidas inicialmente en el análisis orientado a objetos. Debido a que estas clases son centrales al dominio del problema, el número de dichas clases es una indicación del esfuerzo necesario para desarrollar el SW y de la cantidad potencial de reutilización a aplicar durante el desarrollo del sistema.

Número de clases de soporte: las clases de soporte son necesarias para implementar el sistema, pero no están directamente relacionadas con el dominio del problema. Como ejemplo están las clases de la IGU, el acceso a bases de datos y su manipulación y las clases de la comunicación. Adicionalmente las clases de soporte se definen iterativamente a lo largo del proceso recursivo/paralelo. El número de clases de soporte es un indicador del esfuerzo necesario requerido para desarrollar el SW y de la cantidad potencial de reutilización a aplicar durante el desarrollo del sistema.

Número promedio de clases de soporte por clase clave: por lo general las clases claves se conocen al inicio del proyecto, mientras que las de soporte se definen a lo largo de este. Si dado un dominio de problema se conociera la cantidad promedio de clases de soporte por cada clase clave, la estimación se simplificaría mucho.

Número de subsistemas: un subsistema es una agregación de clases que dan soporte a una función visible al usuario final del sistema. Una vez que se identifican los subsistemas, resulta más fácil realizar una planificación razonable en la cual el trabajo en los subsistemas está repartido entre los miembros del proyecto.

Un enfoque orientado a objetos para estimaciones y planificación.

Aunque se pueden usar los conceptos de estimaciones y planificación estudiados antes a los proyectos orientado a objetos, debe tenerse en cuenta que en la mayoría de las empresas de desarrollo de SW, estos son muy recientes y pocos, como para crear una base histórica suficiente. Por ello Lorenz y Kidd sugieren el siguiente enfoque:

Desarrollo de estimaciones usando la descomposición de esfuerzos, análisis de PF, y cualquier otro método aplicable a aplicaciones convencionales.

Desarrollo de guiones de escenario y determinar una cuenta, usando análisis orientado a objetos. Reconozca que el número de guiones de escenarios puede cambiar con el progreso del proyecto.

Determinación de la cantidad de clases clave usando análisis orientado a objetos.

Clasificación del tipo de interfaz para la aplicación y desarrollo de un multiplicador para las clases de soporte:

Tipo de Interfaz Multiplicador

Interfaz no gráfica (no IGU) 2,0

Interfaz de usuario basada en texto

2,25

Interfaz gráfica de usuario (IGU) 2,5

Interfaz gráfica de usuario compleja

3,0

Multiplican el número de clases clave por el multiplicador anterior para obtener una estimación del número de clases de soporte.

Multiplicación de la cantidad total de clases (clave + soporte) por el número de unidades de trabajo por clase. Lorenz y Kidd sugieren entre 15 y 20 días/persona por clase.

Comprobación de la estimación respecto a clases, multiplicando el número promedio de unidades de trabajo por guión de acción.

La planificación para proyectos orientados a objetos es complicada por la naturaleza iterativa del marco del trabajo del proceso. Otras métricas que pueden ayudar a la planificación de proyectos:

Número de iteraciones principales. Número de contratos completos. Seguimiento del progreso en un proyecto orientado a objetos.

El paralelismo del proyecto puede afectar el seguimiento del proyecto. El jefe de proyecto puede tener dificultades al establecer hitos significativos, debido a que ciertas cosas suceden a la vez. En general, los siguientes hitos pueden considerarse terminados al cumplirse los criterios mostrados:

Hito técnico: análisis orientado a objetos terminado.

Todas las clases, y la jerarquía de clases están definidas y revisadas. Los atributos de clases y las operaciones asociadas a una clase se han definido y

revisado. Las relaciones entre clases se han establecido y revisado. Se han creado y revisado un modelo de comportamiento. Se han marcado clases reutilizables.

Hito técnico: diseño orientado a objetos terminado.

El conjunto de subsistemas se ha definido y revisado. Las clases se han asignado a subsistemas y han sido revisadas. Se ha establecido y revisado la asignación de tareas. Se han identificado responsabilidades y colaboraciones. Se han diseñado y revisado atributos y operaciones. El modelo de pase de mensajes se ha creado y revisado. Cada nueva clase ha sido implementada en código a partir del modelo de diseño. Las clases extraídas de una biblioteca se han integrado. Se ha construido un prototipo o incremento.

Hito técnico: prueba orientada a objetos.

La corrección y completamiento del análisis orientado a objetos y del modelo de diseño se han revisado.

Se ha desarrollado y revisado una red de clases – responsabilidades – colaboraciones. Se han diseñado casos de prueba y ejecutado pruebas en el ámbito de clases para cada

clase. Se han diseñado casos de prueba y completado las pruebas de agrupamientos y las clases

se han integrado. Las pruebas al nivel de sistema se han terminado.

Consideraciones del Análisis Orientado a Objetos.

El objetivo del análisis orientado a objetos es desarrollar una serie de modelos que describan al SW de computadoras al trabajar para satisfacer un conjunto de requisitos definidos por el cliente. El modelo de análisis ilustra información, funcionamiento y comportamiento dentro del contexto de los elementos del modelo de objetos.

Para cumplir con el propósito del análisis orientado a objetos se debe hacer lo siguiente:

Los requisitos básicos del usuario deben comunicarse entre el cliente y el ingeniero del SW.

Identificación de las clases (definir atributos y operaciones). Especificación de una jerarquía de clases. Representación de las relaciones de objeto a objeto (conexiones). Modelación del comportamiento del objeto. Repetir iterativamente las tareas anteriores hasta terminar el modelo.

La popularidad de la tecnología orientada a objetos ha generado varios métodos de análisis orientado a objetos. Cada uno introduce un proceso para el análisis de un producto o sistema, un conjunto de modelos que evoluciona fuera del proceso y una notación que posibilita al ingeniero del software crear cada modelo de manera consistente. Analizaremos algunos de los más populares.

En el contexto de la ingeniería del software, se sugiere que el propósito del diseño es construir un sistema que:

Satisface determinada especificación funcional. Se ajusta a las limitaciones impuestas por el medio de destino. Respeta requisitos implícitos o explícitos sobre rendimiento y utilización de recursos. Satisface criterios de diseño implícitos o explícitos sobre la forma del SW. Satisface restricciones sobre el propio proceso de diseño, tales como su longitud o costo, o

las herramientas disponibles para realizar el diseño.

La construcción de modelos goza de amplia aceptación entre todas las disciplinas de ingeniería, sobre todo porque construir un modelo es algo atractivo respecto a los principios de descomposición, abstracción y jerarquía. Cada modelo dentro de un diseño describe un aspecto específico del sistema que se está considerando. Los modelos dan la oportunidad de fallar en condiciones controladas, y modificarlo cuando falla para que se comporte del modo esperado o deseado, sin grandes pérdidas.

La comunidad de la ingeniería del software ha desarrollado docenas de métodos de diseño diferentes. A pesar de sus diferencias, todos estos métodos tienen elementos en común, como son:

Notación: El lenguaje para expresar cada modelo.

Proceso: Las actividades que encaminan a la construcción ordenada de los modelos del sistema.

Herramientas: Los artefactos que eliminan el tedio de construir el modelo y reafirman las reglas sobre los propios modelos, de forma que sea posible revelar errores e inconsistencias.

Un buen método de diseño se basa en fundamentos teóricos sólidos, pero eso no le impide ofrecer grados de libertad para la innovación artística.

Cuando se habla de la aplicación de metodologías orientadas a objetos, debemos considerar que casi todas hablan de establecer tal como en el ciclo de vida clásico del desarrollo de un software, una etapa de análisis y otra de diseño antes de la implementación. En concreto, ¿qué se entiende por estas cosas?.

"El análisis orientado a objetos es un método de análisis que examina los requisitos desde la

perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema".

"El diseño orientado a objetos es un método de diseño que abarca el proceso de descomposición

orientado a objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y dinámico del sistema que se diseña".

Método de Coad y Yourdon.

Este método se considera con frecuencia como uno de los más fáciles de aprender. La notación del modelado es relativamente simple y las reglas para desarrollar el modelo de análisis son evidentes. Consiste en:

Identificación de objetos usando criterios de "que buscar". Definición de una estructura de generalización – especificación. Definición de una estructura de todo – parte. Identificación de temas. Definición de atributos. Definición de servicios. Método de Wirfs y Brock.

Este método no hace una distinción clara entre las tareas de análisis y diseño. En su lugar, se propone un proceso continuo que comienza con la valoración de una especificación del cliente y termina con el diseño. Las tareas relacionadas con este método son:

Evaluación de la especificación del cliente. Uso de un análisis gramatical para extraer clases candidatas de la especificación. Agrupamiento de las clases en un intento de determinar superclases. Definición de responsabilidades para cada clase. Asignación de responsabilidades a cada clase. Identificación de relaciones entre clases. Definición de colaboraciones entre clases basándose en sus responsabilidades. Construcción de representaciones jerárquicas de clases para mostrar relaciones de

herencia. Construcción de un gráfico de colaboraciones para el sistema. Método de Martin y Odell.

Este método es bastante simple y pragmático, pero refleja una concepción de AOO muy cercana a métodos tradicionales pues se hace análisis independiente de la estructura estática y la dinámica de los objetos. En concreto se hace:

Análisis de los requisitos del cliente. Identificación de la estructura estática del objeto.

Modelación del análisis de la estructura del objeto. Identificación de la estructura dinámica de los objetos. Modelación del análisis del comportamiento de los objetos. Modelo de Requerimientos

En su libro de Ingeniería del Software Orientada a Objetos, Jacobson plantea con respecto a su metodología que: "La primera transformación hecha es, de la especificación de los requerimientos, al modelo de requerimientos. El modelo de requerimientos consiste de: un modelo de casos de usos, la descripción de las interfaces y un modelo del dominio del problema".

Los modelos de casos de uso usan dos conceptos básicos: actores y casos de uso. Estos ayudan a definir que existe fuera del sistema (actores) y que debe ser ejecutado por el sistema (casos de uso). En otras palabras, los actores representan lo que interactúa con el sistema, sin querer decir con esto que un actor es un usuario, ya que este último es la persona que realmente usa el sistema, mientras que el actor puede ser el rol que un usuario puede jugar. Por otra parte un caso de uso puede ser considerado una secuencia de transacciones relacionadas contenidas en una interfaz en el sistema.

Un sistema diseñado de esta forma puede ser considerado como un sistema controlado por Casos de Uso. Esto implicaría que cualquier modificación o mejora al sistema implicaría el rediseño del actor y del caso de uso apropiado. "Para soportar el modelo de casos de uso es generalmente apropiado desarrollar también interfaces de los casos de uso".

Para comprender mejor a los casos de uso, es posible modelar sus descripciones como diagramas de transición de estado, en el cual cada estímulo enviado entre un actor y el sistema ejecuta un cambio de estado en el gráfico. La razón por la que se busque inicialmente a los actores está en que ellos son la mejor herramienta para hallar los casos de uso correctamente.

El método de Jacobson conocido también por OOSE (ISWOO), es una simplificación de OBJECTORY, también de Jacobson. Se diferencia de los demás por la importancia que le da al caso de uso que describe como el usuario interactúa con el producto o sistema. Consiste en:

Identificación de los usuarios del sistema y sus responsabilidades globales.

Construcción de un modelo de requisitos.

Definición de los actores y sus responsabilidades.

Identificación de los casos de uso para cada actor.

Preparación de una visión inicial de los objetos del sistema y sus relaciones.

Revisión del modelo usando los casos de uso como escenarios para determinar su validez.

Construcción de un modelo de análisis.

Identificación de objetos de interfaz usando información del tipo actor – interacción.

Creación de vistas estructurales de los objetos de la interfaz.

Representación del comportamiento del objeto.

Aislamiento de subsistemas y modelos para cada uno.

Revisión del modelo usando casos de uso con escenarios para determinar su validez.

En general OOSE está compuesto por cinco modelos que son:

El modelo de requerimientos que ayuda a capturar los requerimientos funcionales.

El modelo de análisis que ayuda a darle al sistema una estructura de objetos robusta y modificable.

El modelo de diseño que ayuda a adaptar y refinar la estructura de objetos al ambiente real de implementación.

El modelo de implementación que ayuda a implementar el sistema.

El modelo de prueba que ayuda a verificar el sistema.

Actividades Obligatorias:

o ¿Cual es el método de Coad y Yourdon? o ¿Cuales son las características de selección de objetos potenciales para incluirlos

en el modelo de análisis que Couad y Yourdon sugieren? o En que consiste el Método de Martin y Odell. o En que consiste el Método de Wirfs y Brock.

Actividades Sugeridas:

o En que consiste el método de Jacobson o ¿Sucede únicamente el polimorfismo cuando hay herencia? o ¿Cuál es el modelo de requerimientos? o ¿Qué es el encapsulamiento?

Autoevaluación:

1. ¿Qué es una superclase? 2. ¿Qué es una subclase? 3. ¿Qué es un atributo? 4. ¿Que son las operaciones? 5. ¿Qué son los mensajes?

3.4.1 MODELO DINAMICO (comportamiento)

Modelos de Objeto y Dinámico

En su libro de Modelación y Diseño Orientado a Objetos, Rumbaugh señala con respecto a su metodología OMT que: "La metodología consiste en construir un modelo de un dominio de aplicación añadiéndosele detalles de implementación durante el diseño del sistema. Esta aproximación se denomina Técnica de Modelado de Objetos (OMT) y consta de las siguientes fases: Análisis, Diseño de Sistema, Diseño de Objetos e Implementación".

La metodología OMT consta para su desarrollo con tres modelos básicos que son:

1. Modelo de Objetos: describe la estructura estática de los objetos del sistema, y también sus relaciones. El modelo de objetos contiene diagramas de objetos, los cuales no son más que grafos cuyos nodos son clases de objetos y cuyos arcos son relaciones entre clases.

2. Modelo Dinámico: describe los aspectos de un sistema que cambian con el tiempo. El modelo dinámico se utiliza para especificar e implementar los aspectos de control del sistema. Los modelos dinámicos contienen diagramas de estado, los cuales no son más que grafos cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por sucesos.

3. Modelo Funcional: describe las transformaciones de valores de datos que ocurren dentro del sistema. El modelo funcional contiene diagramas de flujos de datos, los cuales son grafos cuyos nodos son procesos y cuyos arcos son flujos de datos.

Si algo es importante, entre otras cosas en la OMT es la forma simple en que orienta utilizar el modelo dinámico, o sea los diagramas de estado, para representar una interfaz interactiva hombre – máquina, ya que "el modelo dinámico captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que estén implementadas".

El método de Rumbaugh consiste en:

Desarrollo de una declaración del ámbito del problema.

Desarrollo de un modelo de objetos.

Identificación de clases relevantes al problema.

Definición de atributos y asociaciones.

Definición de enlaces de objetos.

Organización de las clases de objetos usando la herencia.

Desarrollo de un modelo dinámico.

Preparación de escenarios.

Definición de eventos y desarrollo de una traza de eventos para cada escenario.

Construcción de un diagrama de flujos de datos.

Desarrollo de un diagrama de estado.

Revisión del comportamiento para comprobar consistencia y completitud.

Desarrollo de un modelo funcional.

Identificación de entradas y salidas.

Uso de diagramas de flujos de datos para representar transformaciones del flujo.

Desarrollo de especificaciones de proceso para cada función.

Especificación de criterios de restricciones y optimización.

Método de Grady Booch.

En su libro Análisis y Diseño Orientado a Objetos con Aplicaciones, Grady Booch señala que: "Los métodos son importantes por varias razones. En primer lugar, inculcan una disciplina en el desarrollo de sistemas de software complejos. Definen los productos que sirven como vehículo común para la comunicación entre los miembros de un equipo de desarrollo. Además, los métodos definen los hitos que necesita la dirección para medir el progreso y gestionar el riesgo".

El papel del ingeniero como artista es particularmente dificultoso cuando la tarea es diseñar un sistema completamente nuevo. Francamente, es la circunstancia más habitual en la ingeniería del software.

"Es imposible capturar todos los detalles sutiles de un sistema de software complejo en una sola vista. ... Uno debe comprender la estructura taxonómica de las clases, los mecanismos de herencia utilizados, los comportamientos individuales de los objetos y el comportamiento dinámico del sistema en su conjunto".

El método de Booch incluye los siguientes diagramas:

1. Diagramas de Clases. Se usa para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema. Un solo diagrama de clases representa una vista de la estructura de clases de un sistema. Durante el análisis, se utilizan diagramas de clases para indicar las misiones y responsabilidades comunes de las entidades que caracterizan el comportamiento de un sistema. Durante el diseño, se utilizan diagramas de clases para plasmar la estructura de las clases que forman la arquitectura del sistema.

2. Diagramas de Objetos. Se usa para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema. O sea, un diagrama de objetos representa una instantánea en el tiempo de una corriente de eventos sobre una cierta configuración de objetos.

3. Diagramas de Módulos. Se usa para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema.

4. Diagramas de Procesos. Se usa para mostrar la asignación de procesos a procesadores en el diseño físico de un sistema. Un solo diagrama de procesos representa una vista de la estructura de procesos de un sistema.

5. Diagramas de Transición de Estados. Se usa para mostrar el espacio de estados de una clase determinada, los eventos que provocan una transición de un estado a otro, y las acciones que resultan de ese cambio de estado.

6. Diagramas de Interacción. Se usa para realizar una traza de la ejecución de un escenario en el mismo contexto que un diagrama de objetos.

Booch en esencia plantea que para trabajar con su método es conveniente trabajar en dos partes fundamentales: un micro proceso y un macro proceso. Ambas partes incluyen varios pasos como son la identificación de clases y objetos a un nivel de abstracción dado, la identificación de la semántica de esas clases y objetos, la identificación de las relaciones entre esas clases y objetos, la selección de la estructura de datos y algoritmos para la implantación de estas clases y objetos, la conceptualización del sistema, etc. El micro proceso de desarrollo del AOO de Booch incluye:

Identificación de clases y objetos.

Proposición de objetos candidatos.

Conducción del análisis de comportamiento.

Identificación de escenarios relevantes.

Definición de atributos y operaciones para cada clase.

Identificación de la semántica de clases y objetos.

Selección y análisis de escenarios.

Asignación de responsabilidades para alcanzar el comportamiento deseado.

División de las responsabilidades para equilibrar el comportamiento.

Selección de un objeto y enumerar sus papeles y responsabilidades.

Definición de operaciones para satisfacer las responsabilidades.

Búsqueda de colaboraciones entre objetos.

Identificación de interrelaciones entre clases y objetos.

Definición de las dependencias que existen entre objetos.

Descripción del papel de cada objeto participante.

Validación de escenarios por revisión completa.

Realización de una serie de refinamientos.

Producción de los diagramas apropiados para el trabajo realizado en las partes anteriores.

Definición de jerarquías de clases apropiadas.

Creación de agrupamientos basados en clases comunes.

Implementación de clases y objetos.

Actividades obligatorias

o Explique en que consiste el método de Rumbaugh o Explique el Método de Grady Booch. o Explique los diagramas que incluye el método de Booch


o Explique los tres modelos básicos que la metodología OMT consta para su desarrollo

o Mencione lo que incluye el micro proceso de desarrollo del AOO de Booch

Autoevaluación

1. ¿Cuál o en qué consiste el modelo dinámico? 2. ¿Cuál es el método de Grady Booch? 3. ¿Cuál es el modelo funcional? 4. ¿Para qué se usa el diagrama de objetos?

MODULO 4 DISEÑO DE SISTEMAS.

Objetivo.

Aprenderá a cerca de los muchos aspectos del problema de aplicación que deberían considerarse cuando se está formulando un diseño del sistema y los diversos diseños.

Justificación.

En el análisis lo fundamental es lo que necesita hacerse, en el diseño se toman decisiones acerca de la forma en que se resolvera el problema, primero desde un nivel elevado y después empleando niveles cada vez más detallados.

Introducción.

Durante el diseño del sistema se decide la estructura y el estilo global.

OBJETIVO DEL DISEÑO

El diseño es el proceso de determinar cual de muchas posibles soluciones es la mejor para lograr lo que se necesita hacer, respetando las restricciones tecnológicas y de presupuesto del proyecto. El diseño escoge un cómo especifico para aplicarlo al qué.

El diseño consiste en decidir la manera en que debe construirse el sistema para satisfacer los requerimientos de los usuarios. Las buenas metodologías de diseño comparten las siguientes características:

1. El buen diseño debe motivar la toma de decisiones ayudando a evaluar alternativas. Todo el diseño es acerca de compromisos. Una técnica de diseño debe permitir que el diseñador evalúe su decisión contra otras posibilidades. Por ejemplo, usando el modelo de análisis de eventos acoplado con el esquema de diseño de datos, el diseñador puede simular el volumen de lecturas y escrituras a la base de datos para cualquier evento de negocios dado. Esto permite que el equipo evalúe la factibilidad y desempeño proyectado de una disposición de tabla de base de datos dada y de un esquema de distribución de datos antes de construirlos.

2. El diseño necesita ser completo, de tal forma que cubra cada uno de los aspectos principales del software que necesita construirse. Esto causara que se tengan varios tipos diferentes de modelos en la documentación del diseño. Cada modelo está especializado para mostrar un aspecto particular del sistema. Encontrará que los modeladores son particularmente adeptos de la articulación de esos aspectos para los que está orientada la técnica de modelado, pero fallan miserablemente cuando se trata de estirar el modelo más allá de su propósito original. Ningún modelo puede mostrar todas las facetas del sistema funcional completo. Ese sería el sistema mismo.

3. El diseño debe ser verificable antes de su construcción. Uno de los propósitos principales del diseño es revisar y discutir la solución antes de lanzarse a la carga y codificarla. Parte del proceso de verificación es su rastreabilidad. Con una buena especificación del diseño se debe ser capaz de demostrar que se satisfarán los requerimientos del proyecto y así mismo se distinguirá entre varias versiones del diseño en cualquier momento.

4. Una buena metodología de diseño crea productos diferenciados que son mensurables. Una de las tareas más difíciles de cualquier proyecto es estimar cuando se terminará. Para hacer una estimación el gerente del proyecto debe tomar medidas, la cual involucra el conteo de cosas que necesitan hacerse y la aplicación de algún tipo de medida sobre ellas para estimar que tanto tiempo se llevara el hacerlas. La medición viene, por supuesto, de haber contado estas cosas en el pasado y haber medido que tanto tardo el hacerlas anteriormente. Por lo tanto, una metodología de diseño debe producir componentes discretos lo más pronto posible.

5. Por último, pero no menos importante, el diseño debe ser fácilmente aprovechado en el producto final. Debe expresar el uso y la estructura del sistema en una forma muy cercana al resultado pretendido. Este punto puede parecer obvio, pero se ha visto proyectos que trataron de usar técnicas de diseño que fueron completamente inadecuadas para el lenguaje de destino en el que se codifico el sistema. Usted no querría que su arquitecto casero le presentara un plano que fuera tan esotérico que no le diera idea de la forma que tendría la casa en su terreno. El lema de un diseñador es: hacer un mapa de la técnica hacia el destino. Si el sistema va a operar con una base datos relacional se deben escoger tecnicas que sean particularmente adecuadas para el diseño de bases de datos relacionales. Si el sistema empleara un lenguaje orientado a objetos, entonces se deberán usar técnicas de diseño orientado a objetos para las partes del sistema que requieren objetos para lograr sus tareas. Si el sistema incluirá componentes más tradicionales, tales como funciones estructuradas en las rutinas cliente o por lotes en el servidor, entonces son adecuadas técnicas de diseño estructurado más tradicionales para esas partes del sistema.


o Describa con sus propias palabras que es el diseño. o Diga con sus propias palabras cual es el objetivo del diseño. o Describa brevemente las características de las buenas metodologías


o ¿Se diseña software cuando se escribe un programa? o El diseño necesita ser complejo ¿porque?


Pags. 2-3, Análisis y diseño práctico de sistemas cliente/servidor con GUI, 1a. edición, David A. Ruble, Prentice Hall, 1997.

Autoevaluación

1. ¿Qué es el diseño? 2. ¿En que consiste el diseño? 3. ¿Cuáles son las tres características de las 5 buenas metodologías del

diseño? 4. ¿Por qué el diseño debe ser verificable antes de su construcción? 5. ¿Por qué el diseño debe ser aprovechado en el producto final?

4.2 COMO PASAR DEL ANALISIS AL DISEÑO

El análisis es el proceso de determinar qué se necesita hacer, antes de decidir cómo debe hacerse. El diseño escoge un cómo específico para aplicarlo al qué.

Una vez que se ha analizado el problema, es preciso decidir la forma de aproximarse al diseño. El diseño del sistema es la estrategia de alto nivel para resolver el problema y construir una solución. Este incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado.

Durante el análisis, lo fundamental es lo que necesita hacerse, independientemente de la forma de hacerlo. Durante el diseño, se toman decisiones acerca de la forma en que se resolverá el problema, primero desde un nivel un nivel elevado y después empleando niveles cada vez más detallados.

El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. Al tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que trabajaran independientemente en distintos subsistemas. El diseñador de sistemas debe tomar decisiones siguientes:

Organizar el sistema en subsistemas.

Identificar la concurrencia inherente al problema.

Asignar los subsistemas a los procesadores y tareas.

Seleccionar una aproximación para la administración de almacenes de datos.

Manejar el acceso a recursos globales.

Seleccionar la implementación de control en software.

Manejar las condiciones de contorno.

Establecer la compensación de prioridades.

Con frecuencia, la arquitectura global de un sistema se puede se puede seleccionar basándose en su similitud con otros sistemas anteriores. Alguna clase de arquitectura de sistemas son útiles para resolver una amplia gama de problemas. Aunque no todos los problemas se pueden resolver empleando una de estas arquitecturas. Otras muchas arquitecturas se pueden construir combinando estas formas.


o Explique brevemente con sus palabras ¿como pasar del análisis al diseño?. o Cuales son las decisiones que el diseñador deber tomar? o Describa cada uno de ellas.


o Explique que es la arquitectura del sistema o Explique que es la arquitectura global? o ¿Cuál es la diferencia entre arquitectura del sistema y arquitectura global?

Recursos para ampliar el tema Pags. 266-282, Modelado y diseño orientado a objetos, 1a. edición, James Rumbauch,Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, ed Mc Graw Hill, 1997.

Autoevaluación ¿Qué es lo fundamental durante el diseño? Escriba ocho decisiones que un diseñador debe tomar

, ¿Cómo pasar del análisis al diseño?. ¿Qué es la Arquitectura del sistema?

DISEÑO ORIENTADO A OBJETOS

En vez de desarrollar el diseño de un sistema software por medio de una descomposición funcional descendiente, se ha mencionado que la mejor metodología es el diseño orientado al objeto. En este diseño los componentes del software se ven mas como objetos que como funciones. Cada objeto tiene una conjunto asociado de operaciones permitidas, y los objetos se comunican mediante el paso de mensajes que, por lo general, incluyen una instrucción para activar una instrucción para activar una función determinada.

El diseño orientado a objetos se basa en la idea de utilizar ocultamiento de información como principal criterio de descomposición y en la noción de los tipos de datos abstractos. Esta metodología ha sido adoptada de manera entusiasta de algunos desarrolladores y educadores. Abbot ha llegado a decir que "los programas bien escritos en ada suelen ser orientados al objeto", no esta bien escrito. Tales generalizaciones sin comprobar no son de ayuda, y es poco probable que haya alguna metodología de diseño que sea superior a todas las circunstancias. Para situar estos comentarios en perspectiva, se han construido muchos sistemas grandes utilizando el diseño ascendente.

Y pocos con un enfoque orientado al objeto.

Por medio de un funcional, se identificaron las siguientes operaciones:

1. Dividir el documento en palabras. 2. Revisar si las palabras que no están en el diccionario. 3. Formar listas de palabras que no están en el diccionario. 4. Intercalar las palabras buenas en el diccionario, para obtener un nuevo diccionario.

Una nueva visión orientada al objeto de este sistema puede tener como objetos generalizados documentos, diccionarios y listas de palabras. El sistema se puede presentar como un conjunto de objetos actuando recíprocamente.

Esta estrategia depende de la escritura de una descripción informal en lenguaje natural acerca de cómo tratar el problema de diseño. Dada esta descripción, se extraen nombres comunes, con fechas, mensajes, documentos, diccionarios, etc., y se consideran tipos de datos abstractos. Los llamados nombres de más como unidades de medida, nombres de calidades, actividades, etc., también se incluyen en esta categoría.

Los nombres propios y referencias directas a los nombres comunes, por ejemplo la fecha de envío del sistema, un cumpleaños, la propuesta del proyecto, etc., se consideran como casos de tipos de datos abstractos. Los verbos y adverbios se emplean para identificar operadores y atributos de un objeto. Estos se asocian con el correspondiente tipo de datos abstractos.

Este enfoque de diseño orientado al objeto que se basa en una descripción del problema el lenguaje natural parece ser útil en algunas circunstancias. Sin embargo, no esta claro como se puede aplicar al diseño de sistemas grandes y complejos. Cuando un sistema es complejo y con muchas funciones en relación reciproca, es en verdad muy difícil producir una descripción del lenguaje natural y de manera concisa y completa. Por lo tanto, es probable que se presenten errores, omisiones e inconsistencias en la descripción informal de un problema.

Mientras que la resolución de tales errores es siempre un problema de diseño, la falta de estructura y ambigüedad inerte del lenguaje natural dificulta la obtención de una descripción completa del problema. Esto quiere decir que quizá sea necesaria una combinación de estrategias para obtener diseños orientados a objetos; aquí el diseñador utiliza su experiencia e intuición para obtener un diseño a partir de alto nivel del sistema, un modelo funcional descendente, etc., se ha mencionado

que una visión centrada en el objeto de los sistemas de software debe reemplazar por completo la visión funcional. En opción de autor, esto sería un error. Más bien, la descomposición funcional descendente y el diseño orientado a objetos se complementan uno al otro, y cada uno es aplicable en diferentes etapas de diseño del sistema.


o Explique con sus palabras que es el diseño orientado a objetos. o Cuando es probable que se presenten errores.


o Liste 6 lenguajes de programación orientado a objetos o ¿Qué quiere decir "el sistema se puede presentar como un conjunto de objetos

actuando recíprocamente"?


o Pags. 878-894, Análisis y diseño de sistemas, 3a. edición, Kendall & Kendall, ed Pearson educación, 1997.

o Pags. 407-412, Ingeniería de software. un enfoque práctico, 4ª edición, Roger S. Pressman, ed. Mc Graw Hill, 1997

Autoevaluación

1. ¿En que se basa el enfoque de diseño orientado a objetos? 2. ¿Cuales son los tipos de datos abstractos? 3. En que se basa el diseño orientado a objeto

DISEÑO DE LA SALIDA

La salida es la información que se entrega a los usuarios por medio del sistema de información. Algunos datos requieren un procesamiento extenso antes de que se conviertan en salida adecuada, y otros datos son guardados y considerados salida cuando se les recupera con poco o ningún procesamiento. La salida puede tomar muchas formas, la permanente tradicional de los reportes impresos y la fugaz, tal como la de las pantallas VDT, micro formas y sonido. Los usuarios dependen de la salida para realizar sus tareas, y frecuentemente juzgan el mérito de un sistema únicamente por su salida. Para crear la salida más útil posible, los analistas de sistemas trabajan de cerca con los usuarios, por medio de un proceso interactivo hasta que el resultado se considera satisfactorio.

Debido a que la salida es útil es esencialmente para asegurar el uso y aceptación del sistema de información, hay varios objetivos que el analista de sistemas trata de obtener cuando diseña la salida.

1. Diseñar la salida para que sirva al propósito deseado. 2. Diseñar la salida para que se ajuste al usuario. 3. Entregar la cantidad adecuada de salida. 4. Asegurarse de que la salida se encuentra donde se necesita. 5. Entregar la salida a tiempo. 6. Seleccionar el método de salida adecuado.

Diseño de la salida para que sirva al propósito deseado. Toda la salida debe tener un propósito. Durante la fase de análisis de terminación de los requerimientos de información, el analista de sistemas encuentra cuales propósitos deben ser atendidos. La lista es diseñada luego con base en esos propósitos.

Diseño de la salida para el ajuste al usuario. Con un gran sistema de información sirviendo a muchos usuarios para muchos propósitos diferentes, es difícil personalizar la salida que atienda lo que muchos usuarios, aunque no todos necesitan y prefieren. Hablando en termino generales, es más practico crear una salida especifica para el usuario cuando se le diseña para un sistema de soporte de decisiones u otras aplicaciones altamente interactivas.

Entregar la cantidad adecuada de salida. No siempre más es mejor, especialmente cuando se refiere a la cantidad de salida. Parte de la tarea del diseño de la salida es decidir la cantidad de salida que es correcta para los usuarios. Una regla útil es que el sistema debe proporcionar lo que cada personal necesita para completar su trabajo. Sin embargo, esto está todavía muy lejos de ser una solución total, debido a que puede ser adecuado desplegar primero un subconjunto de esa información y luego proporcionar formas para que el usuario accede fácilmente a la información adicional.

Asegurarse de que la salida se encuentra donde se necesita. La salida es impresa en papel, desplegada en pantalla, difundida por bocinas y guardada en micro formas. La salida a veces se produce en un lugar y luego se distribuye a los usuarios. El incremento de salida desplegada en pantallas en línea es accesible personalmente ha reducido en cierta forma el problema de la distribución, pero la distribución adecuada todavía es un objeto importante para el analista de sistemas, para ser usada y útil, la salida debe ser presentada al usuario adecuado.

Entrega de la salida a tiempo. Una de las quejas más comunes de los usuarios es que no reciben la información a tiempo para tomar decisiones necesarias. Los objetivos del analista de sistemas con respecto a la salida con compuestos. No solo se tiene que ser consciente acerca de quien esta recibiendo cual salida, sino también hay que preocuparse de la distribución en el tiempo de la salida para los tomadores de decisiones, mediante esta fase del ciclo de vida del desarrollo de

sistemas ustedes han aprendido que salida es necesaria, y en que momento para dirigir cada etapa de los procesos de la organización.

Selección del método de salida adecuado. Tal como se dijo anteriormente, la salida puede tomar muchas formas, incluyendo reportes impresos en papel, información en pantallas VDT audio con sonidos digitalizados que simulan voz humana y micro formas. La selección del método adecuado de salida para cada usuario es otro objetivo de la salida. El analista necesita reconocer los compromisos involucrados en la sección de un método de salida. Los costos difieren, así como la flexibilidad, tiempo de vida, distribución almacenamiento y posibilidades de recuperación, transportabilidad e impacto general sobre los datos para el usuario. La selección de los métodos de salida no es trivial ni es generalmente una conclusión predecible con certeza.

RELACIÓN DEL CONTENIDO DE LA SALIDA CON EL MÉTODO DE SALIDA.

El contenido de la salida de los sistemas de información debe considerarse interrelacionado con el método de salida. Cada vez que se diseña una salida, es necesario pensar sobre cómo la función influencia la forma y cómo el propósito influencia la salida que se escoge. Se debe pensar en forma general sobre la salida, para que en cualquier información que salga del sistema de cómputo y que sea útil de alguna forma a las gentes, pueda ser considerada la salida.

SELECCIÓN DE LA TECNOLOGÍA DE SALIDA.

El producir diferentes tipos de salida requiere el uso de diferentes tecnologías para la salida de la computadora impresa. Las opciones incluyen impresoras de impacto o no. Para la salida en pantalla las opciones incluyen tubos de rayos catódicos conectados o aislados o pantallas de cristal liquido. La salida de audio puede ser amplificada y emitida por un altavoz o escuchada por medio de bocinas pequeñas en una PC. Las micro formas de salida son creadas por cámaras especialmente equipadas y películas en microficha o microfilm.

FACTORES A CONSIDERAR CUANDO SE SELECCIONA A LA TECNOLOGÍA DE SALIDA.

¿Quién usara la salida? Descubrir quien usara la salida es importante, debido a que los requerimientos de trabajo ayudan a indicar cual es el medio de salida es adecuado. También se aplican diferentes estándares, dependiendo si el receptor de la salida es interno (clientes, vendedores, accionistas y agencias reglamentadoras) requerirán diferente salida que los usuarios internos del negocio. Los clientes a veces tienen dificultad para accesar la salida electrónica, debido simplemente a que ellos no tienen el equipo. En este caso, se les debe proporcionar salida impresa a desarrollar otra interfaz común (como el tono de un teléfono), y en cambio la salida en pantalla, en audio o impresa puede ser viable para uso interno. El conocer quien usara la salida también debe ayudarle a determinar los requerimientos de calidad de la salida.

La salida es cualquier información útil o datos proporcionados por el sistema de información o, el sistema de apoyo a decisiones ante el usuario. La salida puede tomar virtualmente cualquier forma, incluyendo la impresión, pantallas, audio, micro formas, CD-ROM y electrónica.

El analista de sistemas tiene seis objetivos principales para el diseño de la salida. Estos diseñan la salida para que sirva al propósito pretendido y para que se ajuste al usuario, proporcionar la cantidad adecuada de salida, proporcionarla en el lugar adecuado, proporcionar la salida a tiempo y seleccionar el método de salida adecuado.


o Liste 6 objetivos que pretende el analista al diseñar la salida del sistema. o Dé 2 ejemplos que indiquen que la salida en pantallas es la mejor solución para la

selección de tecnología de salida. o ¿Qué tipo de salida es mejor si son una necesidad las actualizaciones frecuentes? o Liste 10 factores que deben ser considerado cuando se escoge la tecnología de

salida.


o ¿Qué tipo de salida es deseable si muchos lectores leerán, guardarán y revisaran la salida a lo largo de varios años?

o ¿Cuáles son las formas de salida? o ¿Cuáles son los lineamientos para el diseño de la pantalla?


Pags. 485-517, Análisis y diseño de sistemas, 3a. edición, Kendall & Kendall, ed Pearson educación, 1997.

Autoevaluación

1. ¿Cual es el diseño de salida? 2. ¿Cómo seleccionar la tecnología de salida? 3. ¿Cómo debe ser la relación del contenido de la salida con el método de

salida? 4. ¿Cuáles son los factores a considerar cuando se selecciona la tecnología

de sali

DISEÑO DE ENTRADA

La calidad de la entrada de un sistema determina la calidad de la salida del sistema. Es vital que las formas y pantallas de entrada sena diseñadas con esta relación critica en mente. Al asistir en entrada bien diseñada, el analista de sistemas está reconociendo que la entrada pobre plantea preguntas sobre la confiabilidad del sistema completo.

Buen Diseño de Formas

Aunque se pueda disponer de especialistas de formas en casa, el analista de sistemas debe ser capaz de reconocer las formas útil. También es importante que sea capaz de reconocer las formas mal diseñadas, traslapantes o innecesarias que están desperdiciando recursos de la organización y que, por lo tanto, deben ser eliminadas. Las formas son instrumentos importantes para dirigir el curso de los trabajos por definición son los papeles impresos o duplicados que requieren que la gente llene con repuestas en una forma estandarizada. Las formas extraen y capturan información requerida por los miembros de la organización que frecuentemente alimentaran a la computadora. Por medio de este proceso, las formas sirven frecuentemente como documentos fuente para el personal de captura de datos.

Cuatro lineamientos para el diseño de formas

Se deben observar cuatro lineamientos del diseño de las formas para diseñar formas útiles:

1. Haga que las formas sean fáciles de llenar. 2. Asegúrese de que las formas satisfacen el objetivo para el que fueron diseñadas. 3. Diseñe formas que aseguren el llenado preciso. 4. Mantenga las formas atractivas.

Hay varios medios para lograr cada lineamiento del diseño de formas.

Flujo de formas. El diseñar una forma con un flujo adecuado puede minimizar el tiempo y esfuerzo gastado por los empleados en el llenado de las formas. Y las formas deben fluir de izquierda a derecha y de arriba hacia abajo.

Secciones de una forma. Otra técnica que facilita a la gente el llenar las formas correctamente es el agrupamiento lógico de la información. Hay 7 secciones principales de una buena forma son:

1. Encabezado. 2. Identificación y acceso. 3. Instrucciones 4. Cuerpo 5. Firma y verificación 6. Totales 7. Comentarios.

La sección de encabezado incluye, por lo general, el nombre y dirección del negocio que envía la forma.

La sección de identificación y acceso incluye código que puede ser usado para archivar el reporte y obtener acceso a él en una fecha posterior. Esta información es muy importante cuando se requiere de una organización conserve el documento por una cantidad de años especificada.

La sección de instrucción dice cómo debe ser llenada la forma y dónde debe ser enviada cuando esté llena.

La parte media de la forma es su cuerpo, que comprende aproximadamente la mitad de la forma. Esta es la parte de la forma que requiere el mayor detalle y desarrollo de la persona que la llena. El cuerpo es la parte de la forma que es más probable que contenga datos variables explícitos. Por ejemplo en una forma de requisición de partes esta sección puede incluir datos tales como la empresa que pide la parte, el número de parte, la cantidad pedida y el precio.

La cuarta parte inferior de la forma está compuesta de tres secciones firma y verificación, totales y comentarios. Al solicitar una firma en esta parte de la forma, el diseñador esta limitando el diseño de otros familiares, tales como cartas. Al solicitar totales finales y un resumen de comentarios es una manera lógica de proporcionar el cierre de la persona que llena la forma.

Diseño de Formas Atractivas

Aunque el atractivo de las formas es dejado al final, su orden de aparición no significa que tenga menos importancia. Las formas estéticas llevan a las gentes hacia ellas y motivan su llenado. Esto significa que las gentes que llenan las formas estarán satisfechas y que las formas serán llenadas. Las formas no deben verse amontonadas, deben parecer organizadas y lógicas después de que son llenadas. Par ser atractivas, las formas deben solicitar la información en el orden esperado, las convenciones indican que se pida el nombre, la calle, la ciudad, estado y el código postal y el país, en caso necesario. La disposición adecuada y el flujo contribuyen el atractivo de la forma. El uso de diferentes tipos de letra dentro de la misma forma puede ayudar a hacer atractivo el llenarla. El separar categorías y subcategorias con líneas gruesas y delgadas también puede motivar el interés por la forma.

Diseño de Formas con Ayuda de Computadoras.

Se dispone de numerosos paquetes de diseño de formas para microcomputadoras. Uno de los mejores paquetes, es llamado FORM LOW de delrina. El FORM LOW ejecuta en el ambiente Windows y su interfaz GUI es familiar par cualquiera que se use en Windows.

Buen Diseño de Pantalla

Mucho de lo que ya hemos dicho acerca del buen diseño de formas se aplica también al diseño de pantallas. Nuevamente, el usuario debe permanecer presente en los pensamientos del analista durante el diseño de pantallas de terminales de desplegado visual (VDT). Bien diseñadas deben satisfacer los objetivos de efectividad, precisión, facilidad de uso, consistencia, simplicidad y atractivo. Todos estos objetivos se logran mediante el uso de principios básicos de diseño, conocimiento de lo que es necesario como entrada para el sistema y una comprensión sobre la manera en que responden los usuarios a los diferentes elementos de las formas y pantallas.

La efectividad significa que las formas y pantallas de entrada sirven a propósitos específicos del sistema de manejo de información y a su vez, la precisión se refiere al diseño que asegura el llenado adecuado, la facilidad de uso significa que las formas y pantallas son directas y no requieren tiempo adicional para decifrarlas. La consistencia significa, en este caso, que las formas y pantallas agrupan los datos en forma similar de una aplicación a la siguiente, y a su vez, simplicidad se refiere a mantener las formas y pantallas intencionalmente sin amontonamiento en una forma que enfoque la atención del usuario. El atractivo implica que los usuarios les agradara o serán atraídos a usar la s formas y pantallas debido a su diseño interesante.

Sin embargo hay diferencias, y el analista de sistemas debe esforzarse para darse cuenta de las cualidades únicas de las pantallas de desplegado, en vez de adoptar a ciegas las convenciones de las formas en papel. Una gran diferencia es la presencia constante de una cursor (un bloque iluminado u otro tipo de apuntador) en pantalla, que orienta al usuario sobre la posición actual de entrada de datos. Conforme los dato son dados a la pantalla, el cursor se mueve un carácter hacia delante indicando el camino.

Lineamientos para el diseño de pantalla

Hay cuatro lineamientos para el diseño de pantalla.

1. Mantener la pantalla simple. 2. Mantener consistente la presentación de la pantalla. 3. Facilitar al usuario el movimiento entre pantallas. 4. Crear una pantalla atractiva.

Secciones de una Pantalla

La pantalla cuenta con tres secciones:

La parte superior de la pantalla tiene una sección de encabezado, parte de la cual está escrita en el software para describir al usuario en que parte del paquete se encuentra. El resto del encabezado puede consistir del nombre de archivo creado por el usuario.

La sección media es llamada el cuerpo de la pantalla. Este puede ser usado para la captura de datos, y es organizado de izquierda a derecha y de arriba hacia abajo. Los títulos e instrucciones deben ser proporcionados en esta sección parta que ayuden al usuario a dar los datos adecuados en el lugar correcto. También se deben proporcionar al usuario las definiciones de campos que muestren que tantos datos se permite en cada campo de la pantalla.

La tercera sección de la pantalla es la sección de comentarios e instrucciones: esta sección puede desplegar un menú corto de comandos que recuerden al usuario los puntos básicos, tales como cambiar pantallas o funciones, guardar el archivo o terminar la captura. La inclusión de estos puntos básicos puede hacer que los usuarios sin experiencia se encuentren mucho mas seguros acerca de su habilidad para operar la computadora sin causar un error fatal.


o ¿Cuáles son los objetivos del diseño para las formas y pantallas del entrada?. o Liste los cuatro lineamientos para el buen diseño de formas. o ¿Cuáles son las siete secciones de una buena forma? o Liste cuatro tipos de titulos que se usan en formas


o ¿Qué es una forma especial? o ¿Cuáles son las 3 secciones simples para simplificar una pantalla? o Liste 4 elementos de diseño de interfaz gráfica. Junto concada uno, decriba

cuando podría ser adecuado incorporar en el diseño de pantalla.



Autoevaluación

1. ¿Cual es el diseño de entrada? 2. ¿Cuales son algunas desventajas del uso de formas especiales? 3. ¿Cómo debe ser el diseño de formas atractivas? 4. ¿Cuáles son las secciones de una pantalla?

DISEÑO DE BASES DE DATOS

El almacenamiento de datos es considerado por algunos como parte medular de los sistemas de información. Los objetivos generales para el diseño de la organización de almacenamiento de datos se muestran en la siguiente figura.

Primero, los datos tienen que estar disponibles cuando el usuario quiere usarlos. Segundo, los datos deben ser precisos y consistentes (deben poseer integridad). Aparte de esto, los objetivos del diseño de base de datos incluyen el almacenamiento eficiente de los datos, así como su eficiente actualización y recuperación. Por ultimo, es necesario que la recuperación de información tenga un propósito. La información obtenida de los datos almacenados debe estar en un formato útil para la administración, planeación, control o toma de decisiones.

ARCHIVOS CONVENCIONALES Y BASES DE DATOS.

Hay dos enfoques para el almacenamiento de datos en un sistema basado en computadora. El primer método es guardar los datos en archivos individuales, cada uno de ellos único para una aplicación particular.

El segundo enfoque para el almacenamiento de datos en un sistema basado en computadora involucra la construcción de una base de datos. Una base de datos es un almacén de datos formalmente definido y centralmente controlado para ser usado en muchas aplicaciones diferentes.

Los archivos convencionales seguirán siendo una forma práctica para guardar datos para algunas aplicaciones (pero no para todas). Un archivo puede ser diseñado y construido muy rápidamente, y las preocupaciones sobre disponibilidad y seguridad de los datos son minimizadas. Cuando los diseños de archivo están cuidadosamente pensados se puede incluir toda la información necesaria, y el riesgo de omitir datos inintencionalmente será bajo.

La velocidad de procesamiento es otra ventaja del uso de archivos. Es posible escoger la técnica optima para el procesamiento de archivos para una sola aplicación, pero es imposible obtener un diseño optimo para muchas tareas diferentes. Cuando la eficiencia del procesamiento es la mayor preocupación, el mejor enfoque puede ser diseñar un archivo individual para ese propósito.

El uso de archivos individuales tiene muchas consecuencias. Frecuentemente los archivos son diseñados solamente con las necesidades inmediatas en mente. Cuando llega a ser importante consultar el sistema para una combinación de algunos de los atributos, esos atributos pueden estar contenidos en archivos separados o puede ser que ni siquiera existan. El rediseño de los archivos implica frecuentemente que, por consecuencia los programas que accedan los archivos deben ser vueltos a escribir. Esto se traduce en tiempo de programadores caro para el desarrollo y mantenimiento de archivos y programas.

Un sistema que usa archivos convencionales implica que los datos guardados serán redundantes. Lo que es mas, la actualización de archivos se lleva mas tiempo. Los archivos poco usados pueden ser olvidados cuando es momento de actualización.

BASES DE DATOS

Las bases de datos no son simplemente un conjunto de archivos. Es una fuente central de datos que esta pensada para que sea compartida por muchos usuarios con una diversidad de aplicaciones. La parte medular de la base de datos es el DBMS (sistema de manejo de base de

datos) que permite la creación, modificación y actualización de la base de datos, la recuperación de datos y la generación de reportes.

Los objetivos de efectividad de la base de datos incluyen:

1. Asegurarse de que la base de datos pueda ser compartida entre los usuarios de una diversidad de aplicaciones. 2. Mantener datos que sean precisos y consistentes. 3. Asegurarse de que todos los datos requeridos para las aplicaciones actuales y futuras estén fácilmente disponibles. 4. Permitir que la base de datos evolucione y que las necesidades de los usuarios crezcan. 5. Permitir que los usuarios construyan su vista personal de los datos sin preocuparse de la forma en que estén físicamente guardados los datos.

El enfoque de base de datos tiene la ventaja de permitir que los usuarios tengan su propia vista de los datos. Los usuarios no necesitan preocuparse de la estructura actual de la base de datos o de su almacenamiento físico.

La primera desventaja del enfoque de base de datos es que todos los datos están guardados en un solo lugar. Los datos son más vulnerables a catástrofes y requieren respaldos completos. Otras desventajas aparecen cuando se trata de lograr dos objetivos de eficiencia para la administración del recurso de datos:

1. Mantener en una cantidad tolerable el tiempo requerido para insertar, actualizar, borrar y recuperar datos.

2. Mantener en una cantidad razonable el costo de almacenamiento de los datos.

Una base de datos no puede ser optimizada para la recuperación de datos de una aplicación especifica, debido a que puede ser compartida por muchos usuarios con diversas, aplicaciones. Lo que es más, se requiere software adicional para la DBMS y, ocasionalmente, se requiere una computadora más grande.

CONCEPTOS DE DATOS.

La realidad, los datos y los metadatos. La relación entre la realidad, los datos y los metadatos se muestra en la siguiente figura:

Entidades. Una entidad puede ser una persona, lugar o cosa. Cualquier entidad también puede ser un evento o unidad de tiempo.

Relaciones. Las relaciones son asociaciones entre entidades (también llamadas asociaciones de datos):

1. Relación uno a uno (indicada como 1:1). 2. Relación de uno a muchos (indicada 1:M), por ejemplo un medico tiene asignados

muchos pacientes, pero un paciente tiene asignado un solo medico. 3. Relación muchos a muchos (indicada M:N) describe la posibilidad de que las

entidades tengan muchas asociaciones en cualquier dirección.

Atributos. Es alguna característica de una entidad. Puede haber muchos atributos para cada cantidad. Son de hecho las unidades más pequeñas en un archivo o base de datos. Pueden tener valores, los cuales pueden ser de longitud fija o variable, pueden ser alfabéticos, numéricos o alfanuméricos.

Registros. Es un conjunto de conceptos de datos que tienen algo en común con la entidad descrita. La mayoría de los registros son de longitud fija y, por lo tanto, no hay necesidad de determinar la longitud del registro cada vez.

Llaves. Es uno de los conceptos de atributos de un registro. Cuando una llave identifica en forma única a un registro es llamada la llave primaria.

Una llave es llamada llave secundaria si no puede identificar en forma única a un registro. Las llaves secundarias pueden usarse para seleccionar un grupo de registros que pertenecen a un conjunto.

Cuando no es posible identificar unos registros en forma única mediante el uso de uno de los conceptos de datos que se encuentran en un registro, se puede construir una clave seleccionando dos o más atributos y combinándolos. A esto se le llama una llave concatenada.

Metadatos. Son datos acerca de los datos del archivo o base de datos. Los metadatos describen el nombre dado y la longitud asignada a cada concepto de datos. Los metadatos también describen la longitud y composición de cada uno de los registros.

ORGANIZACIÓN DE ARCHIVOS.

Un archivo contiene grupos de registros usados para proporcionar información para operación, planeación administración y toma de decisiones.

Tipo de archivos. Los archivos pueden ser usados para guardar datos durante un periodo indefinido de tiempo o pueden ser usados para guardar datos temporalmente para un propósito específico. Los archivos maestros y los archivos de tablas son usados para guardar datos durante un periodo largo. Los archivos temporales son llamados, por lo general, archivos de transacciones, archivos de trabajo o archivos de reporte.

Archivos maestros. Contienen registros de un grupo de entidades. Los atributos pueden ser actualizados frecuentemente, pero los registro mismos son relativamente permanentes. Estos archivos tienden a tener grandes registros que contienen toda la información acerca de una entidad de datos. Cada registro contiene, por lo general, una llave primaria y varias llaves secundarias. Frecuentemente, los archivos maestros son guardados como archivos indexados o secuenciales con índice. Si el archivo maestro es guardado usando métodos de archivo convencional, se reserva un área de expansión al final de cada registro. Esto proporciona espacio para la adición de nuevos campos al registro si es que cambian las necesidades del negocio. Si el archivo es parte de una estructura de base de datos, no se requiere el área de expansión.

Archivos de tablas. Un archivo de tabla contiene datos usados para calcular mas datos o mediadas de desempeño. Los archivos de tablas por lo general son leídos solamente por un programa.

Archivos de transacción. Se usa para capturar cambios para actualizar el archivo maestro y para producir reportes. Los archivos de transacción son mantenidos, por lo general, a una longitud mínima. Pueden contener varios tipos de registro diferentes.

Archivos de trabajo. Un programa puede a veces ejecutar más eficientemente si se usa un archivo de trabajo. Un ejemplo común de un archivo de trabajo es aquel que sido reordenado para que los registros puedan ser acezado mas rápidamente.

Archivos de reporte. Cuando es necesario ejecutar un programa, pero no se dispone de impresora (o esta ocupada imprimiendo otros trabajos), se usa un archivo de reporte. El enviar la salida a un archivo en vez de a la impresora es llamado spooling. Posteriormente, cuando el dispositivo se encuentra listo, se puede imprimir el documento. Los archivos de reporte son muy útiles, debido a que los usuarios pueden llevar los archivos a otros sistemas de computadora y hacer la salida en dispositivos especiales, tales como graficadores, impresoras láser, unidades de microficha y hasta maquinas de composición tipográfica computarizadas.

Organización secuencial. Cuando los registros están físicamente en orden en un archivo se dice que el archivo es un archivo secuencial. Cuando es actualizado un archivo secuencial es necesario recorrer todo el archivo. Debido a que los registros no pueden ser insertados en la parte media del archivo, el archivo secuencial es por lo general, copiado durante el proceso de actualización. Los archivos maestros secuenciales se usan cuando el hardware lo requiere o cuando el acceso normal requiere que sean accesados la mayor parte de los registros. La organización secuencial es usada normalmente para todos los tipos de archivos, a excepción de los archivos maestros.

Listas encadenadas. Cuando se guardan archivos en dispositivos de acceso directo, tales como disco o tambor, las opciones se expanden. Los registros pueden ser ordenados en forma lógica, en vez de física, usando listas encadenadas. Las listas encadenadas se logran usando un juego de apuntadores para dirigirse al siguiente registro lógico que se encuentre ubicado en cualquier parte del archivo.

Organización de archivos de dispersión. La dispersión (hashing) es el proceso de calcular una dirección a partir de la llave de registro.

Hay muchas técnicas de dispersión. Una común es dividir el numero original entre un numero primo que se aproxime a las posiciones de almacenamiento y luego usar el residuo como la dirección.


o Liste algunos ejemplos de entidades y sus atributos. o Defina el término metadato ¿cuál es su propósito?. o ¿Cuáles son las ventajas de organizar el almacenamiento de datos como archivos

separados? o ¿Cuáles son las ventajas de organizar el almacenamiento de datos usando un

enfoque de base de datos? o Liste los tipos de archivo usados comúnmente en archivos convencionales ¿cuáles

de éstos son archivos temporales?


o ¿Qué sucede frecuentemente cuando se usa luna organización de archivos revuelta?

o Nombre los tres tipos principales de organización de base de datos o Indique las diferencias entre "ordenar" e "indexar".



Autoevaluación

1. ¿Cual es el diseño de base de datos? 2. ¿Qué son las bases de datos? 3. ¿cuáles son los tipos de archivos? 4. ¿En que consiste la organización secuencial? 5. ¿Cuáles son las listas encadenadas?

DISEÑO DE LA INTERFAZ HOMBRE-MAQUINA

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 maquina, requeridas para conseguir la función del sistema; se consideran los aspectos de diseño aplicables a todos los diseños del sistema; se consideran los aspectos del 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.

Modelos de Diseño de Interfaz

Cuatro modelos diferentes entran en juego cuando hay que diseñar una interfaz hombre-maquina (IHM). El ingeniero de software crea un modelo de diseño, el "ingeniero del software" establece un modelo de usuario, el usuario final desarrolla una imagen mental que se denomina a menudo el modelo del usuario o la percepción del sistema, y los creadores del sistema crean una imagen del sistema. Desgraciadamente, estos modelos pueden diferir significativamente. El papel del diseñador de interfaces es reconciliar estas diferencias y obtener una representación consistente de la interfaz.

Un modelo de diseño del sistema completo incorpora representaciones de datos, arquitectónicas, de interfaces y procedimentales del software. La especificación de requisitos puede establecer ciertas restricciones que ayudan a definir al usuario del sistema, pero el diseño de interfaz es a menudo secundario en comparación con el modelo de diseño.

Un modelo de usuario muestra el perfil de los usuarios finales del sistema. Para construir una interfaz de usuario eficaz, "todo diseño debería empezar con el conocimiento de los usuarios a los que va dirigido, incluyendo perfiles con el conocimiento de su edad, sexo, capacidades físicas, estudios, historial cultural o étnico, motivación, metas y personalidad". Además, los usuarios se pueden categorizar como:

Novatos: sin conocimientos sintácticos del sistema y escaso conocimiento semántico de la aplicación o del uso de la computadora en general.

Usuarios esporádicos, con conocimientos: conocimiento semántico razonable de la aplicación, pero que recuerda vagamente la información sintáctica necesaria para usar la interfaz

Usuarios frecuentes, con conocimientos: buenos conocimientos semánticos y sintácticos que a menudo conduce al "síndrome de usuario potente", es decir, individuos que buscan accesos directos y modos abreviados de interacción.

La percepción del sistema (modelo del usuario) es la imagen del sistema que lleva en la cabeza el usuario final. Por ejemplo, si el usuario de un procesador de textos particular se le pidiera describir su operación, la percepción del sistema guiaría su respuesta. La exactitud de la descripción dependería del perfil de usuario y de la familiaridad general con el software en el dominio de la aplicación. Un usuario que comprende el funcionamiento de los procesadores de texto totalmente, pero que sólo ha trabajado con este procesador de textos específico, podría ser capaz, de proporcionar una descripción más completa de su función que el novato que ha estado semanas intentando aprenderse el sistema.

La imagen del sistema combina la manifestación exterior del sistema basado en computadora (el aspecto y sensación de la interfaz), con toda la información de soporte (libros, manuales, cintas de vídeo) que describen la sintaxis y semántica del sistema. Cuando coinciden la imagen del sistema y la percepción del sistema, los usuarios se sienten a gusto con el software y lo utilizan eficazmente. Para conseguir esta "fusión" de modelos, el modelo de diseño debe desarrollarse para acomodar la información sintáctica y semántica sobre la interfaz.

Los modelos descritos en esta sección son "abstracciones de los que esta haciendo el usuario o de los que piensa que debería estar haciendo cuando usa un sistema interactivo". En resumen, estos modelos permiten al diseñador de interfaz satisfacer el elemento clave del diseño de interfaz de usuario: " Conocer al usuario, conocer las tareas".

Análisis y Modelado de Tareas

El análisis y modelado de tareas puede aplicarse para entender las tareas que realizan comúnmente los usuarios (cuando usan un manual o un enfoque semiautomático) y después orientarlas en un conjunto similar de tareas (pero no necesariamente idénticas) que se implementan en el contexto de interfaz hombre-maquina. Esto se puede llevar a cabo mediante la observación o estudiando una especificación existente de una solución basada en computadora y obteniendo un conjunto de tareas de usuario que implante el modelo del usuario, el modelo de diseño y la percepción del sistema.

Independientemente del enfoque general del análisis de tareas, el ingeniero del software debe definir y clasificar las tareas. Un enfoque es hacer la elaboración paso a paso.

El modelo de diseño de la interfaz debería acomodar todas estas tareas de manera que sean compatibles con el modelo de usuario y con la percepción del sistema.

Un enfoque alternativo del análisis de tareas toma un punto de vista orientado a objetos. El ingeniero del software observa los objetos físicos que utiliza el diseñador de interiores y las acciones que se aplican a cada objeto. El modelo de diseño de la interfaz no describiría los detalles de la implementación para cada una de estas acciones, pero definiría las tareas del usuario que consiguen el resultado final.

Una vez que se ha definido cada tarea o acción, empieza el diseño de la interfaz. Los primeros pasos en el proceso de diseño de la interfaz se puede llevar a cabo usando el siguiente enfoque:

1. Establecer los objetivos e intenciones de la tarea. 2. Analizar cada objetivo/intención en una secuencia de acciones específicas. 3. Especificar la secuencia de la acción tal y como se ejecutará a nivel de la

interfaz. 4. Indicar el estado del sistema; por ejemplo, ¿cómo es la interfaz cuando se

realiza una acción de la secuencia? 5. Definir los mecanismos de control, por ejemplo, los dispositivos y acciones

disponibles para el usuario para alterar el estado del sistema. 6. Mostrar como afectan los mecanismos de control al estado del sistema. 7. Indicar como interpreta el usuario el estado del sistema por la información

que le proporciona a través de la interfaz.

Aspectos del Diseño

A medida que evoluciona el diseño de la interfaz del usuario, emergen casi siempre cuatro aspectos comunes del diseño: el tiempo de respuesta del sistema, las facilidades de ayuda al usuario, la manipulación de la información de errores y el etiquetado de órdenes. Desgraciadamente, muchos diseñadores no tratan estos aspectos hasta relativamente tarde en el proceso de diseño (a veces la primera indicación de un problema no aparece hasta que tenemos disponible un prototipo en funcionamiento). Casi siempre provoca revisiones innecesarias, retrasos del proyecto y frustración del cliente. Es mucho mejor establecer cada una como un aspecto del diseño a considerar al principio del diseño del software, cuando todavía los cambios son fáciles de realizar y los costes son bajos.

El tiempo de respuesta del sistema es la queja principal de muchos sistemas interactivos. En general, el tiempo de respuesta de un sistema se mide desde el momento en que el usuario realiza alguna acción de control hasta que responde el software con la salida o acción deseada.

El tiempo de respuesta del sistema tiene dos características importantes. Duración y variabilidad. Si la duración del tiempo de respuesta de un sistema es demasiado largo, el resultado inevitable es la frustración y estrés del usuario. Sin embargo, un tiempo de respuesta demasiado corto puede ser también perjudicial si la interfaz le mete prisas al usuario. Una respuesta rápida puede forzar al usuario a correr y, por tanto, a cometer errores.

La variabilidad se refiere a la desviación del tiempo medio de respuesta y en muchos aspectos, es la característica más importante del tiempo de respuesta. Una variabilidad pequeña permite al usuario establecer un ritmo, incluso si el tiempo de respuesta es relativamente largo. Por ejemplo, es preferible un segundo de retardo a una orden que un retardo que varia de 0,1 a 2,5 segundos. En este segundo caso, el usuario está siempre desequilibrado, preguntándose siempre si ha ocurrido algo diferente detrás de bastidores. Casi todos los usuarios de un sistema interactivo basado en computadora necesitan la ayuda de vez en cuando. En algunos casos, una pregunta fácil dirigida a un compañero con más conocimientos basta. En otros, la única opción puede ser hacer una detallada investigación en un conjunto amplio de manuales de usuario. En muchos casos, sin embargo, el software moderno proporciona una ayuda en línea que permite al usuario responder una pregunta o resolver un problema sin abandonar la interfaz.

Encontramos dos tipos diferentes de ayudas. La integrada y la agregada. Una ayuda integrada se diseña en el software desde el principio. Es a menudo sensible al contexto, permitiendo al usuario seleccionarla de los temas relacionados con las acciones que se realizan comúnmente:

Obviamente, esto reduce el tiempo necesario para que el usuario obtenga la ayuda y aumenta la "amigabilidad" de la interfaz. Una ayuda agregada se añade al software después de que se haya construido el sistema. En muchos aspectos, es realmente un manual de usuario en línea con limitada capacidad de consulta. El usuario puede tener que buscar en una lista de cientos de temas para encontrar una ayuda apropiada, haciendo a menudo muchos falsos intentos y recibiendo mucha información que no viene al caso. No hay duda de que es preferible el enfoque de la ayuda integrada al de la agregada.

Cuando se plantea una ayuda se deben tratar varios aspectos del diseño:

¿Estará disponible la ayuda para todas las funciones del sistema y en todo momento durante la interacción con el sistema? Las opciones incluyen desde sólo un conjunto de todas las funciones y acciones hasta la ayuda para todas las funciones.

¿Cómo pedirá el usuario la ayuda? Las opciones pueden ser un menú de ayuda, una tecla de función especial y una orden de AYUDA.

¿Cómo se representará la ayuda? Las opciones incluyen una ventana diferente, una referencia a un documento escrito (algo menos que ideal) y una sugerencia de una o dos líneas en un lugar fijo de la pantalla.

¿Cómo vuelve el usuario a la interacción normal? Las opciones incluyen un botón de vuelta en el monitor y una tecla de función o secuencia de control.

¿Cómo se estructurará la información de ayuda? Las opciones van desde una estructura "plana" en la que toda la información es accesible a través de una palabra clave a una jerarquía estratificada de información que proporciona cada vez más detalles a medida que el usuario se mete más en la estructura y el uso de hipertexto.

Los mensajes de error y advertencias son "malas noticias" enviadas a los usuarios de sistemas interactivos cuando algo ha ido mal. En el peor de los casos, los mensajes de error o advertencias ofrecen información inútil o engañosa y sirven sólo para aumentar la frustración del usuario. Pocos usuarios de computadoras no han topado alguna vez con un error de tipo:

ERROR GRAVE DEL SISTEMA-14 A

En algún lugar debe existir una explicación del error 14 A; sino, ¿por qué habrían añadido los diseñadores la identificación? No obstante el mensaje de error no proporciona ninguna indicación real de los que está mal o donde buscar para obtener información adicional. Un mensaje de error presentado como arriba no hace nada por aliviar la ansiedad del usuario o para ayudar a corregir el problema.

En general, todos los mensajes de error o de advertencia producidos por un sistema interactivo deberían tener las siguientes características:

El mensaje debería describir el problema en un argot que pueda entender el usuario.

El mensaje debería proporcionar una información constructiva para recuperarse del error.

El mensaje debería indicar cualquier consecuencia negativa del error de manera que el usuario pueda comprobarlos para asegurarse de que no ha ocurrido (o corregirlos sí lo están).

El mensaje debería ir acompañado por una señal audible o visible, es decir, se podría generar un pitido para acompañar a la visualización del mensaje, o el mensaje podría parpadear momentáneamente o mostrarse en un color fácilmente reconocible como el "color de error".

El mensaje no debería hacer juicios. Es decir, el texto nunca debería culpar al usuario.

Como a nadie le gustan realmente las malas noticias, a pocos usuarios les gustará el mensaje de error, no importa lo bien diseñado que esté. Pero una filosofía eficaz de mensajes de error puede ayudar mucho a mejorar la calidad de un sistema interactivo y reducirá significativamente la frustración del usuario cuando ocurran problemas.

Las órdenes escritas con el teclado fueron durante un tiempo la forma más común de interacción entre el usuario y el software del sistema, y fue comúnmente usado para aplicaciones de todo tipo. Hoy en día el uso de interfaces orientadas a ventanas, señalización y elección han reducido un modo de interacción orientado a órdenes. En muchas situaciones, se proporciona al usuario una opción: las funciones software se pueden seleccionar de un menú estático o desplegable, o invocado a través de alguna secuencia de órdenes con el teclado.

Cuando se proporcionan órdenes como modo de interacción surgen varios aspectos del diseño:

¿Tendrán todas las opciones del menú su correspondiente orden?

¿Qué formato deben tener las órdenes? Las opciones incluyen una secuencia de control; teclas de función y una palabra escrita.

¿Será difícil aprender y recordar las ordenes? ¿Qué se puede hacer si se olvida una orden?

¿Puede el usuario personalizar o abreviar las órdenes?

En un número creciente de aplicaciones, los diseñadores de interfaces proporcionan una ayuda para macros de ordenes que permite al usuario almacenar una secuencia de órdenes usadas habitualmente bajo un nombre definido por el usuario. En vez de escribir cada orden individualmente (y repetitivamente), se escribe la macro de órdenes y se ejecutan todas las ordenes implicadas en secuencia.

Herramientas de Implementación

El proceso de diseño de la interfaz del usuario es iterativo. Es decir, se crea un modelo de diseño, se implementa como prototipo, lo examinan los usuarios y se modifica basándose en sus comentarios.

Para adaptarse a este enfoque de diseño iterativo han evolucionado una amplia gama de herramientas de diseño de interfaz de creación de prototipos. Denominadas kits de herramientas de interfaz de usuario o sistemas de desarrollo de interfaz de usuario, estas herramientas proporcionan rutinas u objetos que facilitan la creación de ventanas, menús, interacción con dispositivos, mensajes de error, órdenes y muchos otros elementos de un entorno interactivo.

Al utilizar paquetes de software pueden usar directamente el diseñador y el que lo implemente, o bien por la interfaz de usuario, un desarrollo de interfaz de usuario proporciona mecanismos integrados para:

Gestionar dispositivos de entrada (tales como ratón o teclado)

Validar las entradas del usuario

Manejar errores y mostrar mensajes de error

Proporcionar respuestas

Proporcionar ayuda y peticiones de información

Manejar ventanas y campos, controlando el movimiento del texto dentro de ventanas

Establecer conexiones entre el software de aplicación y la interfaz

Aislar la aplicación de las funciones de gestión de la interfaz

Permitir al usuario personalizar la interfaz

Las funciones descritas anteriormente se pueden implementar usando un enfoque gráfico o basado en lenguaje.

Evaluación del Diseño

Una vez que se ha creado un prototipo de interfaz de usuario que funcione, debe evaluarse para determinar si satisface las necesidades del usuario. El espectro de la evaluación puede ir desde una "ejecución de prueba" informal en la que el usuario proporcione sus sensaciones hasta un estudio diseñado formalmente que use métodos estadísticos para la evaluación de cuestionarios rellenados por una población de usuarios finales.

Después de completar el diseño preliminar, se crea un prototipo de primer nivel. El prototipo lo evalúa el usuario, quien proporciona el diseñador comentarios directos sobre la eficacia de la interfaz. Además, si se utilizan técnicas formales de evaluación, el diseñador puede extraer información útil. Las modificaciones del diseño se hacen basándose en la información que aporta el usuario y se crea el prototipo de siguiente nivel. El ciclo de evaluación continua hasta que no son necesarias más modificaciones al diseño de la interfaz. Pero ¿es posible evaluar la calidad de la interfaz de usuario antes de crear un prototipo? Si se pueden descubrir y corregir tempranamente los problemas potenciales, el numero de bucles de ciclo de evaluación se reducirá y se acortara la duración del desarrollo.


o Mencione como se pueden categorizar los usuarios y explique cada uno . o Cuáles son los pasos en el proceso del diseño de la interfaz. Defina cada uno de

ellos. o Explique brevemente los aspectos del diseño


o Explique brevemente en que consiste la evaluación del diseño. o Cuales son las herramientas de implementación. o Explique para que se aplican en el análisis y el modelado de tareas.


Pags. 265-269, Ingeniería de software. un enfoque práctico, 4a. edición, Roger S. Pressman, ed Mc Graw Hill, 1997.

Autoevaluación

1. ¿Qué es el diseño de la interfaz hombre-máquina? 2. ¿Para qué sirven los modelos de diseño de interfaz?

3. ¿Cuáles son los 4 aspectos comunes del diseño que casa siempre emergen a medida que evoluciona el diseño de la interfaz del usuario?

4. ¿Cuál es el papel de diseñador de interfaces?

ESTRUCTURA CLIENTE/SERVIDOR

Las tecnologías de hardware, de software, de bases de datos y de redes contribuyen todas ellas a las arquitecturas de computadoras distribuidas y cooperativas. En su forma mas general, una arquitectura de computadora distribuida y cooperativa se ilustra en la siguiente figura:

Un sistema raíz típicamente será una gran computadora, actúa como deposito de los datos corporativos. El sistema raíz esta conectado con servidores (típicamente son estaciones de trabajo potentes, o PC) y que poseen un doble papel. Los servidores actúan para actualizar y solicitar los datos corporativos mantenidos por el sistema raíz. Además mantienen sistemas departamentales locales y desempeñan un papel clave al poner en red los PC de nivel de usuario a través de una red de área local (LAN).

Una estructura cliente/servidor, la computadora que reside de otra computadora se denomina servidor, y las computadoras de nivel inferior se denominan clientes. Los clientes solicitan servicios, y el servidor los proporciona. Sin embargo, en el contexto de la arquitectura representada en la siguiente figura, se pueden llevar a cabo un cierto numero de implementaciones distintas.

Servidores de archivos. El cliente solicita registros específicos de un archivo. El servidor transmite estos registros al cliente a través de la red.

Servidores de base de datos. El cliente envía solicitudes en lenguaje de consulta estructurado (SQL) al servidor. Estas se transmiten como mensajes a través de la red. El servidor procesa la solicitud SQL y halla la información solicitada, pasando únicamente los resultados al cliente.

Servidores de transacciones. El cliente envía una solicitud que invoca procedimientos remotos en el centro servidor. Los procedimientos remotos pueden ser una conjunto de sentencias SQL. Se produce una transacción cuando una solicitud da lugar a la ejecución de procedimientos remotos y a la transmisión del resultado devuelto al cliente.

Servidores de grupos de trabajo. Cuando el servidor proporciona un conjunto de aplicaciones que hacen posible la comunicación entre clientes (y entre las personas que los usan) mediante el uso de texto, imágenes, boletines electrónicos, vídeo y otras representaciones, existe una arquitectura de grupos de trabajo.

DISTRIBUCION DE LOS COMPONENTES DE SOFTWARE.

Una vez que se han determinado los requisitos básicos de una aplicación cliente/servidor, el ingeniero del software debe de decidir la forma en que distribuirá los componentes de software entre el cliente y el servidor. Cuando la mayor parte de la funcionalidad asociada a cada uno de los tres componentes se le asocia al servidor, se ha creado un diseño de servidor principal (grueso). A la inversa, cuando el cliente implementa la mayor parte de los componentes de interacción / presentación con el usuario, de aplicación y de bases de datos, se tiene un diseño de cliente principal (grueso).

Los clientes principales suelen encontrarse cuando se implementan arquitecturas de servidor de archivo y de servidor de base de datos. En este caso, el servidor proporciona apoyo para la gestión de datos, pero todo el software de aplicación y de IGU reside en el cliente. Los servidores principales son los que suelen diseñarse cuando se implementan sistemas de transacciones y de trabajo en grupo. El servidor proporciona el apoyo de la aplicación necesario para responder a transacciones y comunicaciones que provengan de los clientes. El software de cliente se centra en la gestión de IGU y de comunicaciones.

Se pueden utilizar clientes principales y servidores principales para ilustrar el enfoque general de asignación de componentes de software de cliente/servidor.

Presentación distribuida. En este enfoque la lógica de la base de datos y la lógica de la aplicación permanecen en el servidor, típicamente en una computadora central. El servidor contiene también la lógica para preparar información de pantalla, empleando un software tal como

CICS. Se utiliza un software especial basado en PC para transformar la información de pantalla basada en caracteres que se transmite desde el servidor en una presentación IGU en un PC.

Presentación remota. La lógica primaria de la base de datos y de la aplicación permanecen en el servidor, y los datos enviados por el servidor serán utilizados por el cliente para preparar la presentación del usuario.

Lógica distribuida. Se asignan al cliente todas las tareas de presentación del usuario y también los procesos asociados a la introducción de datos tales como la validación de nivel de campo, la formulación de consultas de servidor, y las solicitudes de informaciones de actualizaciones del servidor. Se asignan al servidor las tareas de gestión de las bases de datos, y los procesos para las consultas del cliente, para actualizaciones de archivos del servidor, para control de versión de clientes, y para aplicaciones de ámbito general de la empresa.

Gestión de datos remota. Las aplicaciones del servidor crean una nueva fuente de datos dando formato a los datos que se han extraído de alguno otro lugar. Las aplicaciones asignadas al cliente se utilizan para explotar los nuevos datos a los que se ha dado formato mediante el servidor.

Bases de datos distribuidas. Los datos de que consta la base de datos se distribuyen entre múltiples clientes y servidores. Consiguientemente, el cliente debe de admitir componentes de software de gestión de datos así como componentes de aplicación y de IGU.

DISEÑO PARA SISTEMAS C/S

Cuando se esta desarrollando un software para su implementación empleando una arquitectura de computadoras concreta, el enfoque de diseño debe de considerar el entorno especifico de construcción. En esencia, el diseño debería de personalizarse para adecuarlo a la arquitectura del hardware.

Cuando se diseña software para su implementación empleando una arquitectura cliente/servidor, el enfoque de diseño debe de ser "personalizado" para adecuarlo a los problemas siguientes:

El diseño de datos domina el proceso de diseño. Para utilizar efectivamente las capacidades de un sistema de gestión de bases de datos relacional (SGBDR) o un sistema de gestión de bases de datos orientado a objetos (SGBDOO) el diseño de los datos pasa a ser todavía más significativo que en las aplicaciones convencionales.

Cuando se selecciona el paradigma controlado por sucesos, el modelado del comportamiento (una actividad de análisis), deberá de realizarse y será preciso traducir los aspectos orientados al control implícitos en el modelo de comportamiento al modelo de diseño.

El componente de interacción/presentación del usuario de un sistema C/S implementa todas aquellas funciones que se asocian típicamente con una interfaz gráfica de usuario (IGU).

Suele seleccionarse un punto de vista orientado a objetos para el diseño. En lugar de la estructura secuencial que proporciona un lenguaje de procedimientos se proporciona una estructura de objetos mediante la vinculación entre los sucesos iniciados en la IGU y una función de gestión de sucesos que reside en el software basado en el cliente.

DISEÑO DE BASES DE DATOS

El diseño de bases de datos se utiliza para definir y después especificar la estructura de los objetos de negocios que se emplean en el sistema cliente/servidor. Es preciso desarrollar toda una gama de informaciones de diseño durante el diseño de base de datos. Esta información, implementada mediante el uso de una base de datos relacional. Se podrá mantener en un deposito de diseño modelado en la figura que muestra a continuación:

Se utilizan tablas individuales del lado izquierdo del diagrama para definir la siguiente información de diseño para la base de datos cliente/servidor:

Entidades: se identifican en el diagrama entidad relación del nuevo sistema. Archivos: que implementan las entidades en el diagrama entidad relación. Relación entre campo y archivo: establece la disposición de los archivos al identificar los

campos que están incluidos en cada archivo. Campos: define los campos del diseño (el diccionario de datos). Relaciones entre archivos: identifican los archivos relacionados que se pueden unir para

crear vistas lógicas o consultas. Validación de relaciones: identifica el tipo de relaciones entre archivo o entre archivos y

campos que se utilicen para la validación. Tipos de campo: se utiliza para permitir la herencia de características de campos

procedentes de superclases del campo (por ejem.: fecha, texto, numero, valor, precio). Tipo de datos: las características de los datos contenidos en el campo. Tipo de archivo: se utiliza para identificar cualquiera de las ubicaciones del archivo. Función de campo: clave, clave externa, atributo, campo virtual, campo derivado, etc. Valores permitidos: identifica los valores permitidos para los campos de tipo de estado. Reglas de negocios: reglas para editar, calcular campos derivados, etc.

En el contexto del diseño de bases de datos, un problema fundamental es la distribución de datos. Esto es, ¿cómo se distribuyen los datos entre el cliente y el servidor y cómo se dispersan entre los nudos de la red?

Un sistema de base de datos relacional (SGBDR) hace fácil el acceso a datos distribuidos mediante el uso del lenguaje de consulta estructurado (SQL). La ventaja de SQL en una arquitectura C/S es que "no requiere navegar". La implicación de esto es que el sistema de base de datos relacional debe de ser suficientemente sofisticado para mantener la ubicación de todos los datos y tiene que ser capaz de definir la mejor ruta hasta ella. En sistemas de bases de datos menos sofisticados, una solicitud de datos debe de indicar a que hay que acceder y donde se encuentra. Si el software de aplicación debe de mantener la información de navegación, entonces la gestión de datos se vuelve mucho más complicada por los sistemas C/S.

Es preciso tener en cuenta que también están disponibles para el diseñador otras técnicas para la distribución y gestión de datos:

Extracción manual. Se permite al usuario copiar manualmente los datos adecuados de un servidor a un cliente. Este enfoque resulta útil cuando el usuario requiere unos datos estáticos, y cuando se puede dejar el control de la estación en manos del usuario.

Instantánea. Esta técnica automatiza la extracción manual al especificar una "instantánea" de los datos que deberán de transferirse desde un cliente hasta un servidor a intervalos predefinidos. Este enfoque es útil para distribuir unos datos relativamente estáticos que solamente requieran actualizaciones infrecuentes.

Duplicación. Se puede utilizar esta técnica cuando es preciso mantener múltiples copias de los datos en distintos centros. En este caso, el nivel de complejidad se incompleta porque la consistencia de los datos, las actualizaciones, la seguridad, y el procesamiento deben de coordinarse entre los múltiples centros.

Fragmentación. Este enfoque, la base de datos del sistema se fragmenta entre múltiples máquinas. Aunque resulta intrigante en teoría, la fragmentación es excepcionalmente difícil de implementar, y hasta el momento no es frecuente encontrarla.


o Empleando publicaciones comerciales o recursos de internet de información de fondo, defina un conjunto de criterios para evaluar herramientas para la ingeniería de software cliente/servidor.

o Investigue los últimos avances en el software para trabajo en grupo y desarrolle un resumen breve.

o Ofrezca ejemplos de de tres o cuatro mensajes que pudieran dar lugar a una solicitud de un método de cliente mantenido en el servidor

o Investigue cuales son los componentes de software para sistemas cliente/servidor


o Sugiera cinco aplicaciones en las cuales un servidor principal parezca una estrategia de diseño adecuada.

o Sugiera cinco aplicaciones en las cuales el cliente principal parezca ser una estrategia de diseño adecuada

o Investigue un lenguaje de consulta estructurado (SQL) y proporcione un breve ejemplo de la forma en que se podría caracterizar una transacción empleando ese lenguaje.



Autoevaluación

1. ¿En qué consiste el diseño en ambiente de redes? 2. ¿Cómo se debe ser la estructura de los sistemas cliente / servidor? 3. ¿Cuáles son las cinco configuraciones diferentes para la asignación de

componentes de software? 4. ¿Cómo debe ser el diseño para sistemas cliente/servidor? 5. ¿Para qué es necesario el diseño de bases de datos en el ambiente de

redes?

DISEÑO DE TIEMPO REAL

El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseño del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las características del sistema operativo, por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño.

La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto de gasolina de nuestras últimas generaciones de coches y programar a nuestros aparatos.

Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora esta controlando algo que interactúa con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción.

Consideraciones Sobre los Sistemas

Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, par conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento.

El problema para los sistemas de tiempo real es realzar la asignación importante como la función, pero las decisiones de asignación relativas al rendimiento son frecuentemente difíciles de hacer con seguridad.

¿Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un hardware especial para hacer el trabajo?

¿Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el ingeniero de sistemas de tiempo real.

SISTEMAS DE TIEMPO REAL

Los sistemas de tiempo real generan alguna acción en respuesta a sucesos externos. Para realizar esta función, ejecutan una adquisición y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real están frecuentemente dedicados a una única aplicación.

Durante muchos años, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reducción del coste del hardware ha hecho posible para la mayoría de las compañías, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatización industrial, investigación medica y científica, gráficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentación industrial.

Aspecto de Integración y Rendimiento

Globalmente, un sistema de tiempo real enfrenta al ingeniero de sistemas con difíciles decisiones sobre el software. Una vez que el elemento software ha sido asignado, se establecen los requisitos detallados del software y debe desarrollarse un diseño fundamental de software.

Entre los muchos aspectos relativos al diseño de tiempo real están: la coordinación entre las tareas de tiempo real, el procesamiento de interrupciones del sistema, el manejo de E/S para asegurar que no se pierden datos, la especificación de las ligaduras de tiempo externas e internas del sistema y el asegurar la precisión de su base de datos.

Cada diseño de tiempo real relativo al software debe ser aplicado en el contexto del rendimiento de sistema. En la mayoría de los casos, el rendimiento de un sistema de tiempo real se mide con una o más características relativas al tiempo, pero también se utilizan otras medidas, tales como la tolerancia al fallo. Algunos sistemas de tiempo real se han diseñado para aplicaciones en las que solo el tiempo de repuesta o la trasferencia de datos es critica. Otras aplicaciones de tiempo real requieren la optimización ambos parámetros bajo unas condiciones de carga extremas. Y lo que es mas, los sistemas de tiempo real deben manejar sus cargas máximas, mientras se ejecutan varias tareas simultáneamente.

Puesto que el rendimiento de un sistema de tiempo real se determina principalmente por el tiempo de respuesta del sistema y su razón de transferencia de datos, es importante comprender estos dos parámetros. El tiempo de respuesta del sistema es el tiempo en el que un sistema debe detectar un suceso interno o externo y responder con una acción. Frecuentemente, la detección del suceso y la generación de la respuesta son tareas sencillas, Es el procesamiento de la información sobre el suceso para determinar la respuesta adecuada lo que puede implicar algoritmos complejos que consumen mucho tiempo.

Entre los parámetros clave que afectan al tiempo de respuesta esta el cambio de contextos y la latencia de la interrupción. El cambio de contexto se refiere al tiempo y sobrecarga necesitado para conmutar entre tareas, y la latencia de interrupción es el tiempo que pasa antes de que el cambio sea realmente posible. Otros parámetros afectan al tiempo de repuesta son la velocidad de calculo y el acceso a memorias masivas.

La razón de transferencia de dato sindica con que rapidez se introducen o salen del sistema los datos series o paralelos, tanto los analógicos como digitales.

Los sistemas de tiempo real necesitan normalmente para procesar un flujo continuo de datos de llegada. El diseño debe asegurar que no falte ningún dato. Además, un sistema de tiempo real debe responder a los sucesos que son asíncronos. Por lo tanto, la secuencia de llegada y el volumen de los datos no pueden predecirse fácilmente de antemano.

Aunque todas las aplicaciones de software deben ser fiables, los sistemas de tiempo real hacen una especial demanda de fiabilidad, re inicialización y recuperación de fallos. Debido a que el mundo real está siendo monitorizado y controlado, la pérdida de monitorizado o control (o cambios) es intolerable en muchas circunstancias.

Consecuentemente, los sistemas de tiempo real contienen mecanismos de restauración y recuperación de fallos y frecuentemente tienen incorporados redundancias para asegurar la restauración.

Sin embargo, la necesidad de fiabilidad ha estimulado un continuo debate sobre los sistemas interactivos, tales como los sistemas de reserva de billetes y cajeros automáticos de los bancos, también son de tiempo real. Por otra parte, tales sistemas interactivos deben responder a interrupciones externas dentro de tiempos de respuesta prescritos en el orden de un segundo.

Manejo de Interrupciones

Una característica que sirve para distinguir a los sistemas de tiempo real de cualquier otro tipo es el manejo de interrupciones. Un sistema real debe responder a un estimulo externo –interrupción- en un tiempo dictado por el mundo externo. Debido a que frecuentemente, se presentan múltiples estímulos (interrupciones), deben establecerse prioritarias, en otras palabras, la tarea más importante debe ser siempre ser servida de las ligaduras de tiempo predefinidas, independientemente de otros sucesos.

El manejo de interrupciones supone, no solo almacenar información, de forma que la computadora pueda restablecer correctamente la tarea interrumpida, sino también evitar interbloqueos y bucles sin fin. El enfoque global para el manejo de interrupciones, el flujo normal de procesamiento es interrumpido por un suceso que es detectado por el hardware del procesador. Un suceso es cualquier ocurrencia que necesita un servicio inmediato y puede ser generado por hardware o por software se salva el estado del programa interrumpido, es decir, se guardan todos los contenidos de los registros, los bloques de control, etc. Y se pasa el control a una rutina de servicio de interrupción, que bifurca al software apropiado para el manejo de la interrupción.

BASES DE DATOS DE TIEMPO REAL

Como muchos sistemas de procesamiento de datos, los sistemas de tiempo real, frecuentemente, van junto con una función de gestión de base de datos. Sin embargo, puede parecer que las bases de datos distribuidas constituyen el método preferido en los sistemas de tiempo real, debido a que multitarea es muy común y que los datos se procesan frecuentemente en paralelo. Si la base de datos es distribuida y no centralizada, las tareas individuales pueden acceder a sus datos de forma rápida, fiable y con menos cuellos de botella. El uso de una base de datos distribuida par aplicaciones de tiempo real divide el trafico de entrada/salida y acorta las colas de las tareas en espera, para acceder a una base de datos raramente causará el fallo del sistema entero si se construyen con redundancia.

Las eficiencias del rendimiento conseguido mediante el uso de una forma de base de datos distribuida, debe ser sopesada frente a cualquier problema potencial asociado con la partición y replicación de los datos. Aunque la redundancia de los datos mejora el tiempo de requisitos de replicación para los archivos distribuidos también producen problemas logísticos y de sobrecarga, puesto que todas las copias de los archivos deben ser actualizadas, además el uso de base de datos distribuida introduce el problema de control de concurrencia. El control de concurrencia implica la sincronización de las bases de datos de forma que todas las copias tengan la misma y correcta información disponible para los accesos.

El método convencional para el control de concurrencia se basa en lo que se conoce como bloqueo y estampado de tiempo. En intervalos regulares, se inician las siguientes tareas: las bases de datos son bloqueadas de forma que se asegure el control de concurrencia, se realiza la actualización requerida.

Sin embargo, se han desarrollado algunas técnicas para aumentar la velocidad de actualización y resolver el problema de concurrencia. Una de estas, llamada protocolo del escritor exclusivo, mantiene la consistencia de los archivos replicados, permitiendo que sólo una tarea de escritura actualice un archivo en exclusiva. Por tanto se elimina la gran sobrecarga de los procesamientos de bloqueo y estampado de tiempo.

SISTEMAS OPERATIVOS DE TIEMPO REAL

Hoy, dos amplias clases de sistemas operativos se utilizan los trabajos de tiempo real. Un sistema operativo de tiempo real diseñado exclusivamente para aplicaciones de tiempo real y sistemas operativos de propósito general que se han reforzado para suministrar capacidades de tiempo real. El uso de un ejecutivo de tiempo real hace factible el rendimiento en tiempo real para un sistema operativo de propósito general comportándose como software de aplicación, el ejecutivo ejecuta varias funciones del sistema operativo, particularmente las que afectan al rendimiento de tiempo real de una forma más rápida y eficiente que el sistema operativo de propósito general.

Todos los sistemas operativos deben tener un mecanismo de planificación de prioridades, pero un sistema operativo de tiempo real debe dar mecanismo de prioridades que permita que las interrupciones de prioridad alta tengan precedencia sobre la menos importante. Además, debido a que las interrupciones de prioridad ocurren en respuesta a sucesos asíncronos no recurrentes, deben ser servidas sin consumir primero un tiempo de respuesta de carga de un programa de disco. Consecuentemente para garantizar el tiempo de respuesta requerido, un sistema operativo de tiempo real debe tener un mecanismo de bloqueo de memoria, esto es, mantener unos mínimos

programas en memoria principal, de forma que se evite la sobrecarga del almacenamiento en la misma.

Para determinar cuando una aplicación, puede definirse y evaluarse medidas de la calidad de sistema operativo de tiempo real.

LENGUAJES DE TIEMPO REAL

Debido a los requisitos especiales de rendimiento y de fiabilidad demandados por los sistemas de tiempo real, es importante la elección del lenguaje de programación. Puede usarse con efectividad muchos lenguajes de programación de propósito general. Sin embargo una clase llamada lenguajes de tiempo real, se utilizan frecuentemente en aplicaciones especializadas de comunicaciones y militares.

Varias características a un lenguaje de tiempo real diferente de un lenguaje de propósito general. Estas incluyen la capacidad de multitarea, construcciones para implementación directa de funciones de tiempo real y características modernas de programación que ayuden a asegurar la corrección del programa.

Es importante que el lenguaje de programación soporte directamente la multitarea debido a que los sistemas de tiempo real deben responder a sucesos asíncronos que ocurren simultáneamente. Aunque sistemas operativos de tiempo real dan capacidad multitarea, frecuentemente existe software de tiempo real empotrado sin un sistema operativo. En vez de ello, las aplicaciones se escriben en un lenguaje que da un soporte de tiempo real suficiente para la ejecución del programa de tiempo real. El soporte de tiempo de ejecución requiere menos memoria que un sistema operativo y puede ser adaptado a una aplicación, incrementando así el rendimiento.

SINCRONIZACIÓN Y COMUNICACIÓN DE TAREAS.

Un sistema de multitarea debe suministrar un mecanismo por que el que las tareas se pasen información unas a otras, así como para asegurar su sincronización. Para estas funciones, los sistemas operativos y los lenguajes con soporte de tiempo real, utilizan frecuentemente semáforos de colas, buzones o sistemas de mensajes. Los semáforos suministran sincronización y señalización pero no contienen información. Los mensajes son similares a los semáforos, excepto en aquellos que llevan una información sino que la contienen.

Los semáforos de colas son primitivos de software que ayudan a gestionar el trafico. Suministran un método para dividir varias colas. Por ejemplo colas de tareas en espera de recursos, acceso a bases de datos o dispositivos, así como colas de recursos y dispositivos. Los semáforos coordinan (sincronizan) las tareas en espera con lo que estén esperando, sin dejar que las tareas o recursos interfieran entre sí.

En un sistema de tiempo real, los semáforos se utilizan frecuentemente para implementar y gestionar buzones. Los buzones se almacenan temporalmente en lugares también llamados buffers o almacenas de mensajes para evitar mensajes de un proceso a otro. Un proceso produce una información, la sitúa en el buzón y luego señala a un proceso consumidor que hay una información en el buzón para que la utilice.

Algunos métodos para los sistemas operativos de tiempo real o sistemas de soporte de tiempo de ejecución ven los buzones como forma más eficiente de implementar comunicaciones entre los procesos. Algunos sistemas de tiempo real suministran un lugar para evitar y recibir referencias a los datos del buzón. Esto elimina la necesidad de transferir todos los datos ahorrando así tiempo y sobrecarga.

ANÁLISIS Y SIMULACION DE SISTEMAS DE TIEMPO REAL.

Requisitos funcionales de un sistema de tiempo real:

Manejo de interrupciones y cambio de contexto.

Tiempo de respuesta.

Razón de transferencia de datos y tiempo invertido.

Asignación de recursos y manejo de prioridades

Sincronización de tareas y comunicaciones entre tareas.

Puede especificarse cada uno de estos atributos de rendimiento, pero es extremadamente difícil verificar si los elementos del sistema consiguen las respuestas deseadas, si los recursos del sistema consiguen las respuestas deseadas, si los recursos del sistema serán suficientemente para satisfacer los requisitos computacionales o si los algoritmos de procesamiento se ejecutaran con la velocidad suficiente.


o Indique cinco ejemplos de sistemas de tiempo real basados en computadora. Indique que "estímulos" alimentan al sistema y qué dispositivos o situaciones controla o supervisa el sistema.

o Proporcione tres ejemplos en los que los semáforos sean un mecanismo apropiados de sincronización de tareas.

o Obtenga información sobre una o más herramientas de análisis formales para sistemas de tiempo real.

o Describa las bases de datos en tiempo real


o Explique los sistemas operativos en tiempo real o ¿Cuáles son las características de un lenguaje de tiempo real? o Mencione los requisitos funcionales de un sistema de tiempo real



Autoevaluación

1. ¿En qué consiste el diseño en tiempo real? 2. ¿Qué son los sistemas de tiempo real? 3. ¿Cuáles son los sistemas operativos en tiempo real? 4. ¿En qué consiste la sincronización y comunicación de tareas?

Modulo 5

CODIFICACION

Objetivo.

Presentar de forma simple, las técnicas para construir software correcto, robusto y reusable.

Justificación.

Ciertamente, hay que tomar decisiones mientras se escribe el código, pero cada una de ellas debería de afectar solamente a una pequeña parte del programa, de tal manera que fuera fácil cambiarlas. La escritura del código debe ser sencilla, casi mecánica, porque ya deberíamos de haber tomado todas las decisiones durante el diseño.

Introducción.

La escritura del codigo es la extensión del proceso del diesño es decir la personificación última de la solución del problema, por eso hay que tomar decisiones mientras se escribe el codigo pero cada una de ellas debera afectar solamente una parte del programa, de tal manera que sea mas fácil cambiarlas.

COMO PASAR DEL DISEÑO A LA CODIFICACIÓN

Elección de un lenguaje

Es la decisión más importante que debe de tomarse al diseñar un sistema grande de software la de tomar en consideración el lenguaje de software que va a utilizar en la aplicación del sistema.

Ya que la mayoría de las veces el costo se produce en fases de prueba de un sistema y en el mantenimiento del ciclo de vida, un empleo inapropiado de una notación puede ocasionar dificultades posteriores.

Este problema puede desaparecer si solo se dispone de un lenguaje de programación o si el cliente demanda alguno en particular.

Una buena elección de un lenguaje es importante porque reduce al mínimo las dificultades de codificar un diseño, reduce la cantidad de pruebas necesarias haciendo el programa más legible y más fácil de mantener.

La aplicación del sistema debe ser fácil de mantener, por lo tanto esto implica que debe codificarse en un lenguaje de alto nivel que nos proporcione la posibilidad de construir un sistema como varios módulos autónomos cooperativos. Tendrá el lenguaje como característica que debe producir un programa legible.

Entre los criterios que se aplican para la evaluación de lenguajes disponibles están:

1. Los requisitos del contratista del sistema. La persona que contrata el sistema puede especificar que se utilice determinado lenguaje específico y debemos respetar ese requisito, y debe el diseñador del proyecto o realizador decir cual es el lenguaje que será mas apropiado para realizar el sistema.

2. Disponibilidades de compiladores del lenguaje. Si realizaremos una aplicación por medio de la configuración de un sistema operativo o un hardware en particular, debe disponerse de un traductor del lenguaje de aplicación de aceptable eficiencia para aplicar el lenguaje.

3. Disponibilidad de instrumentos de software para apoyar el desarrollo de los programas. Instrumentos de software, construcciones de referencia cruzada, sistemas para control de código, y analizadores de flujo de ejecución, son importantes en el apoyo del proceso de programación. Pues facilitan la aplicación y confirmación del sistema.

4. Tamaño del proceso. Es recomendable diseñar y diseñar un lenguaje de programación especifico para él.

5. Conocimiento del personal de programación existente. Aunque no es una dificultad para un programador aprender un nuevo lenguaje, necesitan adquirir práctica en algún lenguaje antes de adquirir una verdadera competencia.

6. Lenguaje de programación utilizado en proyecto previo. Esto se utiliza cuando los programadores han trabajado en un lenguaje anterior, ya se familiarizan con él.

7. Necesidad de transportar el software. Si esta orientado el software a una sola configuración de hardware y tiene un tiempo de vida limitado, los aspectos de su transporte no son limitados. Si el sistema esta destinado a operar en maquinas distintas es necesario un lenguaje de programación capaz de crear programas portátiles.

8. La aplicación que se esta programando. Influye en gran medida respecto al lenguaje que se utilizara.

Lenguaje de programación e ingeniería de software

Independientemente del paradigma o ingeniería del software, el lenguaje de programación tendrá impacto en la planificación, el análisis, el diseño, la codificación, la prueba y el mantenimiento.

La calidad del resultado final se encuentra mas fuertemente unida a las actividades de ingeniería de software que preceden y sigue a la codificación. La planificación de herramientas de soporte asociadas con la definición de recursos puede requerir que se especifique un compilador en especial (o software asociado) o un entorno de programación.

Una vez establecidos los requisitos, las técnicas de los lenguajes de programación candidatos, se hace más importante. En estos tenemos que tomar en cuenta si se requiere que el lenguaje soporte complejas estructuras de datos, si lo más importante es un alto rendimiento y posibilidades de tiempo real o para eficiencia en memoria y velocidad, etc.

En algunas ocasiones los requisitos del diseño solo se pueden satisfacer cuando un lenguaje tiene características especiales. Al Igual que ocurre con la prueba, no se comprende totalmente el efecto de las características de los lenguajes de programación sobre el mantenimiento del software. No hay duda sin embargo de que las características técnicas pueden mejorar la legibilidad del código y reducir la complejidad, lo que es importante para el mantenimiento efectivo del sistema.

Estilo de codificación

Una vez generado el código fuente, la función de un módulo debe ser clara sin necesidad de referirse a ningún diseño, el código debe ser comprensible(debe mezclarse la simplicidad con la claridad). Entre los elementos de estilo se encuentran la documentación interna(a nivel código fuente), los métodos de declaración de datos, enfoque de construcción de sentencias y las técnicas de entrada y salida.


o Seleccione cualquier lenguaje especializado y prepare resumen de sus características importantes y sus posibilidades especiales. Escriba un pequeño programa que ilustre la sintaxis del lenguaje.

o Seleccione algún lenguaje orientado a los objetos y prepare un resumen de sus características importantes y de sus posibilidades especiales. Escribe un pequeño programa que ilustre la sintaxis del lenguaje.

o Seleccione algún lenguaje de cuarta generación y prepare un resumen de sus características importantes y de sus posibilidades especiales.


o Las aplicaciones de sistemas expertos es una de las muchas áreas de aplicación especializadas. Investigue sobre los lenguajes LISP y PROLOG y resuma sus potentes posibilidades y debilidades en esa área de aplicación ¿en qué se parecen los lenguajes? ¿en qué se diferencian?

o Ada es un gran lenguajes de programiopn con un gran abanico de posibilidades. ¿En qué se diferencia Ada de los lenguajes de programación como PASCAL ó C?


Pags. 544-559, Ingeniería de software. Un enfoque práctico, 3a. edición, Roger S. Pressman, ed Mc Graw Hill, 1997.

Autoevaluación

1. ¿Qué es un lenguaje de programación? 2. ¿Cómo debe ser el estilo de codificación? 3. ¿Cuáles son los criterios que se aplican para la evaluación de lenguajes

disponibles?

DOCUMENTACIÓN DE CODIGO

La documentación comienza con la elección de los nombres de los identificadores(variables y etiquetas), continúa con la localización y composición de los comentarios y termina con la organización visual del programa.

La elección de nombres de identificadores significativos es crucial para la legibilidad. Los lenguajes que limitan la longitud de los nombres de las variables o de las etiquetas a unos pocos caracteres, implícitamente limitan la comprensión. Considere las siguientes sentencias:

D=V * T

DIST= VELHOR * TIEMPO

DISTANCIA=VELOCIDAD.HORIZONTAL * TIEMPO TRANSCURRIDO EN SEG.

La posibilidad de expresar los comentarios en el lenguaje natural como parte del listado de código fuente es algo que aparece en todos los lenguajes de programación de propósito general. Sin embargo surgen ciertas preguntas:

¿Cuántos comentarios son "suficientes"?

¿Dónde se deben situar los comentarios?

¿Oscurecen los comentarios la lógica del programa?

¿Pueden los comentarios distraer al lector?

¿Son los comentarios "no mantenibles", y por lo tanto, no fiables?

Hay pocas respuestas definitivas a las preguntas anteriores. Pero una esta muy clara:

El software debe contener documentación interna. Los comentarios permiten al programador comunicarse con otros lectores do código fuente. Los comentarios pueden también resultar una clara guía de comprensión durante la última fase de la ingeniería de software –el mantenimiento -.

Existen varios modelos propuestos para la creación de comentarios.

Los comentarios de prólogo y los comentarios descriptivos son dos categorías que requieren un enfoque diferente. Al principio de cada módulo, debe haber un comentario de prólogo. El formato para estos comentarios es el siguiente:

1. Una sentencia de propósito que indique la función del módulo. 2. Una descripción de la interfaz que incluya:

a. Un ejemplo de la "secuencia de llamada" b. Una descripción de todos los argumentos. c. Una lista de todos los módulos subordinados.

1. Una explicación de los datos pertinentes, tales como las variables importantes y su uso, de las restricciones y de las limitaciones y de otra información importante.

2. Una historia del desarrollo que incluya:

a. El diseñador del módulo (autor).

b. El revisor (auditor) y fecha. c. Fechas de modificación y descripción.

Comentarios descriptivos.

Los comentarios descriptivos se incluyen en el cuerpo del código fuente y se usan para describir las funciones del procesamiento. "los comentarios deben proporcionar algún extra no solamente parafrasear el código"

Además los comentarios descriptivos deben:

Describir los bloques de código en vez de describir cada línea.

Usar líneas en blanco o tabulaciones de forma que sean fácilmente distinguibles del código.

Que sean correctos, un comentario incorrecto o que se pueda interpretar mal es peor que no ponerlo.

Con unos recursos nemotécnicos apropiados para los identificadores y unos buenos comentarios se asegura una documentación interna adecuada.

Cuando se representa un diseño de procedimientos detallado mediante un lenguaje de diseño de programas, se puede incluir directamente la documentación del diseño en el listado fuente como sentencias de comentario. Esta técnica es particularmente útil cuando la implementación se lleva a cabo en lenguaje ensamblador y ayuda a asegurar que, tanto el código como el diseño, podrán fácilmente mantenerse al hacer cambios sobre ellos.

El sangrado del código fuente realza las construcciones lógicas y los bloques de código, tabulando desde el margen izquierdo de forma que se vean desplazados estos atributos. Actividades Obligatorias

o Explique cómo deben ser los nombres de los identificadores. o Explique para que sirven los comentarios o En qué parte van los comentarios de prologo o Escriba cual es el formato para los comentarios de prologo.


o En que parte van los comentarios descriptivos. o Como deben ser los comentarios descriptivos. o Cuál es la mejor forma de hacer el sangrado.


Pags. 560-563 , Ingeniería de software. Un enfoque práctico, 3a. edición, Roger S. Pressman, ed Mc Graw Hill, 1993.

Autoevaluación

1. ¿Cómo debe ser la documentación del código? 2. ¿Qué es la documentación interna? 3. ¿Cuáles son las carácteristicas que deben contener los comentarios

descriptivos?

DECLARACION DE DATOS

La complejidad y la organización de las estructuras de datos se definen durante el paso de diseño. El estilo de la declaración de datos se establece cuando se genera el código. Se pueden establecer varios métodos para hacer más comprensibles los datos y más fáciles de mantener.

El orden de las declaraciones de datos, debe estandarizarse aunque un lenguaje de programación no tenga requisitos específicos.

Por ejemplo el orden de declaración en un módulo en FORTRAN sería la siguiente:

1. Todas las declaraciones explícitas(para mas claridad deben de declararse todas las variables)

INTEGER, REAL, DOUBLE PRECISION,.......

2. Todos los bloques de datos globales.

COMMON/nombrebloque/....

3. Todos los arrays globales

DIMENSION nombre de arrays y dimensiones.

4. Todas las declaraciones de los archivos.

DEFINE FILE, OPEN, CLOSE.

El orden hace que los atributos sean fáciles de descubrir, comprobar, depurar y mantener.

Cuando se declaran múltiples nombres de variables en una sola sentencia, merece la pena ponerlos en orden alfabético, al igual las etiquetas.

Si el diseño prescribe una estructura de datos compleja, se deben usar comentarios para explicar las particularidades inherentes a la implementación en el lenguaje de programación.


o ¿Qué diferencia el diseño de la codificación? o ¿En qué momento se establece el estilo de la declaración de datos? o ¿Cómo debe ser el orden de las declaraciones?


o Explique porqué el orden hace que los atributos sean fáciles de descubrir, comprobar, depurar y mantener.

o Cuando se declaran múltiples nombres de variables en una sola sentencia que se recomienda hacer

Recursos para ampliar el tema Pags. 563, Ingeniería de software. Un enfoque práctico, 3a. edición, Roger S. Pressman, ed Mc Graw Hill, 1993.

Autoevaluación

¿Qué es la declaración de datos? ¿Cómo debe ser la declaración de datos? ¿Porqué se deben usar comentarios?

CONSTRUCCION DE SENTENCIAS

La construcción de flujo lógico del software se establece durante el diseño. La construcción de sentencias individuales, sin embargo, es parte del paso de codificación. La construcción de sentencias se debe basar en una regla general: cada sentencia debe ser simple y directa; el código no debe ser retorcido aunque se precise una mayor eficiencia.

Muchos lenguajes de programación permiten disponer múltiples sentencias en una misma línea el ahorro de espacio que esto implica esta difícilmente justificado por la pobre legibilidad del resultado. Considere los siguientes segmentos de código:

Do I=1 to n-1; T=I; Do J=I+1 to n; If A(j)<A(t) then Do t=j; End; If t<>I then Do H= A(t); A(t)=A(I); A(I)=T; End; end;

La estructura de bucles y Las operaciones condicionales del anterior segmento están enmascaradas por la construcción de múltiples sentencias por línea. Reorganizando el formato el formato del código:

Do I=1 to n-1; T=I; Do J=I+1 to n; If A(j)<A(t) then Do t=j; End; If t<>I then Do H= A(t); A(t)=A(I); A(I)=T; End; end;

Aquí, la sencilla construcción de las sentencias y el sangrado dan luz sobre las características lógicas y funcionales del segmento. Las sentencias de código fuente individuales se pueden simplificar al:

Evitar el uso de complicadas comparaciones condicionales.

Eliminar comparaciones con condiciones negativas.

Evitar un gran anidamiento de bucles o condiciones.

Usar paréntesis para clasificar las expresiones lógicas o aritméticas.

Usar espacios o símbolos claros para incrementar la legibilidad del contenido de la sentencia.

Usar solo características del estándar ANSI.

Pensar "¿Podría yo entender eso si fuera la persona que lo codifico?


o La construcción de sentencias se deben basar en una regla general, diga cual es y expliquela con sus palabras.

o Qué implica poner multiples sentencias en una sola línea o ¿Cómo se pueden simplificar las sentencias de código


o Explique que quiere decir "usar espacios y/o simbolos claros para implementar la legibilidad del contenido de la sentencia.

o ¿Porqué usar párentesis para clarificar las expresiones lógicas o aritméticas?


Pags. 563 - 564, Ingeniería de software. Un enfoque práctico, 3a. edición, Roger S. Pressman, ed Mc Graw Hill, 1993.

Autoevaluación

1. ¿En que momento se establece la construcción del flujo lógico? 2. Escribe 3 formas de como se puede simplificar las sentencias del codigo

fuente 3. ¿Porqué el código es menos legible si se encuentra escrito todo en una

sola linea?

ENTRADA / SALIDA

El estilo de entrada salida se establece durante el análisis de requisitos del software y el diseño. Sin embargo, la forma en que se implementa la E/S puede ser una característica determinante de la aceptación del sistema por una comunidad de usuarios. El estilo de entrada y salida variará con el grado de interacción humana. Para una E/S orientada a lotes serán deseables características tales como una organización lógica de entrada, una comprobación de errores de entrada/salida significativa, una buena recuperación de errores de E/S. Para la E/S interactiva lo principal será un esquema de entrada simple y dirigida, una extensa comprobación y recuperación de errores, una salida humanizada y una consistencia de formatos de E/S.

Serie de principios de estilo para la E/S durante el diseño y la codificación:

Validar los datos de entrada. Comprobar las importantes combinaciones de elementos de entrada. Mantener el formato de entrada simple. Usar el indicativo de fin de dato, en lugar de pedir al usuario especificar el número de

elementos. Etiquetar peticiones interactivas de entrada, especificando los valores posibles o valores

limites. Mantener el formato de entrada uniforme cuando un lenguaje de programación tenga

estrictos requisitos de formato. Etiquetar todas las salidas y diseñar todos los informes.

El estilo de E/S se ver afectado por muchas otras características, tales como los dispositivos de

E/S, la sofisticación del usuario y el entorno de comunicación. Actividades Obligatorias

o Cuando se establece la entrada y la salida. o ¿Qué es lo principal para una entrada/salida interactiva? o Escriba la serie de principios de estilo para la entrada/salida durante el diseño y la

codificación


o ¿Porqué otras características se ve afectado el estilo de entrada/salida? o ¿Por qué etiquetar todas las salidas y diseñar todos los informes? o ¿Porqué validar todos datos de entrada?



Autoevaluación

1. ¿En qué consiste la entrada/salida? 2. ¿En qué consiste la entrada/salida orientada a lotes? 3. ¿Con que puede variar el estilo de entrada/salida?

REUTILIZACION

El software reutilizable reduce los costes de diseño, codificación y comprobación, porque se amortiza el esfuerzo a lo largo de varios diseños. Al reducirse la cantidad de código se simplifica también la comprensión, lo cual hace que aumente la probabilidad de que el código sea correcto. La reutilización es posible en los lenguajes convencionales, pero los lenguajes orientados a objetos incrementan mucho la posibilidad de que se reutilice el código.

Clase De Reutilización.

Hay dos clases de reutilización: Compartir un código recién escrito dentro de un proyecto, y volver a utilizar un código previamente escrito en proyectos nuevos. Se pueden aplicar unas líneas generales a las dos clases de reutilización. Compartir código dentro de un proyecto es una cuestión de descubrir secuencias de código redundantes dentro del diseño, y de utilizar las capacidades del lenguaje de programación (los procedimientos o métodos) para compartir su implementación. Este tipo de código compartido casi siempre resulta beneficioso de manera inmediata, produciendo unos programas más pequeños, mas correcciones más rápidas y una iteración del diseño más ágil.

El planeamiento para una futura reutilización requiere mas anticipación y representa una inversión. Es probable que una clase aislada se utilice para múltiples proyectos. Los programadores suelen reutilizar unos subsistemas cuidadosamente pensados, tales como tipos abstractos de datos, paquetes gráficos y bibliotecas de análisis numérico.

Reglas De Estilo Para La Reutilización

Mantener la coherencia de métodos. Un método es coherente si lleva a cabo una única función o un grupo de funciones íntimamente relacionadas. Si hace dos o más cosas que no este relacionadas, hay que descomponerlo en métodos más pequeños.

Mantener pequeños métodos. Si un método es muy extenso, descompóngalo en métodos más pequeños. Un método que vaya mas allá de una o dos paginas será probablemente, demasiado grande al descomponer los métodos en piezas más pequeñas, quizá sea posible reutilizar algunas piezas, aun cuando el método completo no resulte reutilizable.

Mantener la congruencia de los métodos. Los métodos similares deberían de tener los mismos nombres, condiciones, orden de argumentos, tipos de datos, valor proporcionado y condiciones de error. Hay que mantener la estructura paralela siempre que sea posible.

Separar la política de la implementación. Los métodos de política toman decisiones, bajan argumentos, y recogen el contexto global. Los métodos de política conmutan el control entre métodos de implementación. Los métodos de política deberían de comprobar el estado y los errores; no deberían efectuar directamente cálculos, ni tampoco deberían de implementar algoritmos complejos. Los métodos de política suelen ser muy dependientes de la aplicación, pero son fáciles de escribir y fáciles de entender.

Proporcionar una cobertura uniforme. Si las situaciones de entrada se pueden producir en distintas combinaciones, hay que escribir métodos para todas las combinaciones, y no solo para aquellas que sean necesarias tan solo en el presente.

Generalizar el método lo más posible. Intente generalizar los tipos de argumentos, las condiciones previas y restricciones, las suposiciones acerca de la forma en que funciona el método, y el contexto en el que funciona el método. Lleve a cabo acciones significativas cuando los valores estén vacíos, cuando sean valores extremos, y cuando los valore queden fuera de los

limites. Con frecuencia, es posible hacer mas general un método mediante un ligero incremento de código.

Evitar la información global. Minimice las referencias externas. La alusión a un objeto global impone el contexto requerido a la utilización del método. Con frecuencia, la información se puede pasar como argumento. En caso contrario, almacenar la información global como parte del objeto blanco, para que los otros métodos puedan acceder a ella de manera uniforme.

Evitar los modos. Las funciones que modifican drásticamente su comportamiento dependiendo del contexto en curso son difíciles de reutilizar. Intente sustituirlas por funciones sin modo.

Recursos De Software Reutilizable

Cada día toma más importancia la estimación del software reutilizable como recurso, por cuanto contribuye al aumento de la productividad en el proceso de la ingeniería de software. Bennatan sugiere estas categorías de software reutilizable:

Componentes ya desarrollados. Software existente que puede adquirirse o que fue desarrollado por el equipo antes y que están totalmente validados.

Componentes ya experimentados. Análisis, Diseños, Códigos o Pruebas existentes y usados en proyectos anteriores pero similares al software en creación. Las modificaciones serán de bajo costo.

Componentes con experiencia parcial. Lo mismo a lo anterior, pero con posibles modificaciones más sustanciales, que pueden implicar más riesgo.

Componentes nuevos. Lo que debe crearse específicamente para este proyecto de software.

El software reutilizable como recurso debe cumplir con lo siguiente: Si los componentes ya desarrollados cumplen los requisitos, hay que adquirirlos. El costo de adquisición y acople de los componentes ya desarrollados es generalmente menor al de desarrollo de nuevos componentes, además el riesgo es bajo.

Si se dispone de componentes ya experimentados, los riesgos asociados a la modificación y la integración, son generalmente aceptables.

Si se dispone de componentes de experiencia parcial, su uso debe analizarse en detalle. Su uso depende del grado de mantenimiento requerido. El costo de modificación del software existente suele ser mayor que el costo de un nuevo desarrollo.


o Uno de los obstáculos principales de la reutilización consiste en hacer que los desarrolladores de software consideren la reutilización de componentes ya existentes, en lugar de volver a inventar otros nuevos. (¡después de todo, es divertido construir cosas!) Sugiera tres o cuatro formas distintas en que una organización de software pueda proporcionar incentivos para que los ingenieros de software utilicen la reutilización. ¿Que tecnologías deberían estar implantadas para apoyar ese esfuerzo de reutilización?

o Entre los "artefactos de reutilización" descritos en el libro ingeniería de software. un enfoque práctico, 4a. edición de Roger S. Pressman, se cuenta los planes de proyectos y las estimaciones de costes. ¿Cómo es posible reutilizar estos objetos y cuales son los beneficios derivados de hacer esto?

o Explique que es la reutilización y porque es importante.


o Explique con qué debe cumplir el software reutilizable como recursos

o Explique las clases de reutilización


o Pags. 372 - 374, Modelado y diseño orientado a objetos, 1a. edición, James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, ed. Prentice Hall, 1991.

o Pags. 485 - 499, Ingeniería de software. Un enfoque práctico, 4a. edición, Roger S. Pressman, ed Mc Graw Hill, 1997.

Autoevaluación

1. ¿Qué es la reutilización? 2. ¿Cuáles son las categorias de software reutilizable? 3. Nombre las cuatro reglas de estilo para la reutilización

USO DE BIBLIOTECAS

Las librerías son elementos indispensables en la construcción de programas. Algunos lenguajes entregan más facilidades para la utilización y creación de estas librerías.

Por ejemplo en C, se encuentran disponibles gran cantidad de librerías, entre las que se pueden mencionar stdio.h, conio.h, string, bios.h, memory.h, allec.h,...etc. cada una con funciones y declaraciones que pueden ser utilizados para algún fin.

Pero también es posible que el programador pueda crear sus propias librerías que le ayuden a resolver un problema particular, pero que posteriormente pueda ser re-utilizada en otro proyecto posterior.

El uso de librerías es tremendamente útil, nos permiten agrupar varias funciones y variables en un mismo fichero, de manera que luego podemos incluir esta librería en distintas páginas y disponer de esas funciones fácilmente.

Lo lógico, en cualquier sistema operativo, o cualquier programa, es que las cosas que haya que realizar muy repetitivamente, se haga desde un solo sitio. Con ello, tendremos tres ventajas:

1. Ahorro de esfuerzos. Si ya esta hecho, se utiliza sino se hace (pensándolo bien) y se utiliza desde cualquier sitio.

2. Lo haga bien o lo haga mal, al menos está en un solo sitio. Fácil de localizar para su arreglo si tenemos problemas.

3. Fácil de mantener. Debido al punto 2) si necesitamos cambiar o ampliar su funcionalidad, está en un solo sitio y solo debemos tocar en ese sitio.

El objetivo que se persigue con la creación de librerías de funciones, como las DLLs, es poder aprovechar el mismo código desde diferentes aplicaciones, lo que supone un ahorro evidente en cada una de esas aplicaciones. Para que crear una función nueva para llevar a cabo lo mismo que me ofrece una función ya creada y probada.

Una librería DLL (Librería de Enlace Dinámico[Dynamic Link Library]), es un archivo ejecutable en donde se encuentran funciones y/o Recursos (Bitmaps, Definiciones de Fuentes,...), que pueden ser llamados y utilizados por cualquier aplicación en tiempo de ejecución. La ventaja de las DLL frente a las librerías convencionales es que sólo se cargan en memoria, cuando se necesitan los recursos de esa DLL. Hace varios años esto resultaba muy útil, ya que la memoria era muy limitada. Aunque con el uso de DLL la estabilidad del sistema es menor que con el uso de librerías estáticas.

Las características de un sistema que utiliza DLL’s son:

Las aplicaciones ligan el código de la librería, reduciendo el espacio de almacenamiento y evitando la duplicación de código.

Una aplicación que utiliza DLL’s se comporta idénticamente a cualquier otra aplicación que utiliza las mismas DLL’s.

Si un problema surge, o se quiere añadir una nueva característica, simplemente se actualizan las DLL’s y todas las aplicaciones resultan beneficiadas.

Como se mencionó anteriormente una DLL debe ser cargada en el espacio de direcciones de un proceso y ello se puede hacer de dos maneras: implícitamente y explícitamente.

a. Enlazado Implícito. Cuando se enlaza una aplicación se debe pasar una lista de archivos LIB. Los archivos LIB, en la programación Windows, contienen una lista de las funciones que las DLL permiten llamar. Cada DLL tiene su correspondiente archivo LIB. Cuando el enlazador se percata que la aplicación está llamando a una función incluida en el archivo

LIB de una DLL, pone información adicional en la imagen del EXE que indican el nombre de la DLL que se requiere. Luego, cuando el sistema operativo carga el EXE, recorre esta lista de DLL’s necesarias y trata de cargarlas una por una.

Cuando el sistema operativo busca una DLL, recorre los siguientes directorios:

1. El directorio de contiene la imagen del EXE. 2. El directorio actual del proceso. 3. El directorio de sistema de Windows. 4. El directorio Windows. 5. Los directorios de la variable PATH.

Si el archivo no se puede encontrar, el sistema muestra un mensaje en la pantalla indicando el error y termina el proceso. Cuando se utiliza este método las proyecciones de las DLL’s en el espacio de direcciones no se eliminan hasta que termina el proceso.

a. Enlazado Explícito. Es posible proyectar una DLL en el espacio de un proceso en tiempo de ejecución llamando a la función LoadLibrary o LoadLibraryEx.

Ambas funciones tratan de cargar una DLL en el espacio de direcciones de un proceso.

Ventajas e Inconvenientes del uso de DLLs

El uso de este tipo de archivos ofrece una serie de ventajas que se pueden resumir en:

Una función definida dentro de una DLL se encuentra disponible para cualquier aplicación Windows.

Reducción del tamaño de las aplicaciones que utilizan la DLL, por la Reutilización de su código. Este hecho comporta dos ventajas añadidas, como son:

Mejora en el tiempo de compilación y/o carga de la aplicación (el tamaño del código se ha reducido)

Ahorro de espacio en disco, esa función se encuentra una sola vez en el disco, independientemente del número de aplicaciones que la usen.

Las DLLs son independientes de la aplicación

Sin embargo, no todo son ventajas. Existe también, como no, algún inconveniente que podríamos resumir en:

Tienen que estar presentes antes de ser usadas.

Tiempo de Acceso a la DLL por parte de la aplicación que usa esa DLL.

Para poder acceder a las funciones de esa DLL, existen dos métodos alternativos, que denominaremos: Llamada Estática y Llamada Dinámica a una DLL

Llamada Estática a DLL

También conocido como Enlace Estático, es un método que emplea la librería estática (archivo .lib) generada durante el proceso de creación de la DLL.

En este método, durante el proceso de compilación de la aplicación se produce el enlace entre la DLL y la aplicación que la va a usar. Más en concreto se produce durante el proceso de linkado de la aplicación que va a usar la DLL, cuando se enlazan los módulos objeto (.obj), los archivos de librerías en tiempo de ejecución (.lib) y, en el caso de existir, los archivos de recursos compilados (.res) para generar un único archivo ejecutable (.exe) para Windows.

A partir de esto, se puede deducir que la librería queda incluida dentro del archivo ejecutable, lo que lleva consigo una serie de ventajas, como pueden ser:

Al estar incluida dentro del ejecutable, la librería se carga al inicio de la aplicación y se descarga al finalizar la ejecución de nuestra aplicación. Esto hace que se cumpla uno de los requisitos de las DLLs consistente en que siempre deben estar presentes.

La llamada a las funciones contenidas en la DLL se realizará de igual forma como se realizan las llamadas a cualquier otra función implementado en el código de nuestra aplicación. Esto es debido a que se encuentran en la misma zona de memoria de la aplicación y, como se conoce su posición exacta, ya que se ha fijado durante la carga del ejecutable. Este aspecto, favorece muy mucho la implementación del código necesario para el acceso a las funciones de la DLL.

Pero como no todo pueden ser ventajas, también aparecerá algún inconveniente que se puede resumir en:

Debido a que la DLL se carga junto como el ejecutable de la aplicación y se descarga al finalizar la aplicación, no hay forma de poder controlar lo que sucede durante los procesos de carga y descarga de la DLL. Así pues, se puede dar el caso que se intente acceder a una DLL que no se ha podido cargar en memoria por el motivo que sea.

Al estar incluido el archivo .lib dentro del archivo ejecutable (.exe) de la aplicación, cualquier cambio que se produjera en la DLL que se está ejecutando supondría tener que recompilar esta aplicación, para obtener dentro del archivo ejecutable (.exe) la nueva versión del archivo (.lib).

AL incluir el archivo .lib dentro del ejecutable de nuestra aplicación, comporta un incremento del tamaño del archivo.exe. Esto conlleva, entre otras cosas, que la DLL esté ocupando, durante toda la ejecución de la aplicación, un cierto espacio de memoria. Esto será así, aun cuando no se acceda en ningún momento, durante toda la ejecución de la aplicación, a las funciones de la DLL.

Llamada Dinámica a DLL

La Llamada Dinámica a DLL, también conocido como Enlace Dinámico, es un método que emplea la librería dinámica (archivo .dll) generada durante el proceso de creación de la DLL.

En este método, el enlace entre la DLL y la aplicación que la va a usar, se producirá durante la ejecución de la aplicación. Como se ha visto antes, la Llamada Estática apostaba por asegurar la presencia de la DLL en todo momento.

Por su parte, la Llamada Dinámica apuesta por tener un mayor control sobre los procesos de carga/descarga de la DLL, así como obtener una mayor independencia entre la DLL y la aplicación que la va a usar. Entonces, la DLL no será incluida dentro del ejecutable, sino que será cargada cuando sea necesaria y será descargada en el momento en que ya no sea necesaria. Esta carga/descarga de la DLL en función de su uso, nos permite una mejor gestión de los recursos, pues no ocupará espacio en memoria, a menso que sea necesario. Además, nos proporcionará un alto grado de control sobre el proceso de carga y descarga de la DLL.

Vamos a llevar esto a la práctica. Cuando se desee acceder a las funciones implementadas dentro de la DLL, deberemos proceder, si es necesario, a cargarla en memoria de la DLL.


o Explique las tres ventajas del uso de bibliotecas o Explique las características de un sistema que utiliza DLL's o Liste las ventajas del uso de las DLL's


o Explique el enlace estático a DLL o Explique el enlace dinámico a DLL o Busque en libros o internet mas información acerca del tema y haga un resumen


o Pags. http://www.duiops.net/windows/articulos/desde23.htm o http://www.webestilo.com/php/php05b.phtml

Autoevaluación ¿Qué son las librerías y para que sirven? ¿Cuál es el objetivo de la creación de librerías de funciones? ¿Qué son las DLL's? ¿Cuáles son las desventajas?

EFICIENCIA

Aunque la eficiencia es un fin recomendable, se deben establecer tres máximas antes de pasar a una discusión más profunda:

1. La eficiencia es un requisito de rendimiento y como tal, se debe establecer durante el análisis de requisitos del software. El software debe ser tan eficiente como se requiera, no tan eficiente como sea humanamente posible.

2. La eficiencia se incrementa con un buen diseño. 3. La eficiencia del código y la simplicidad del código van de la mano.

En general, no hay que sacrificar la claridad, la legibilidad o la corrección en aras de unas mejoras en eficiencia que no sean esenciales.

Eficiencia En Código

La eficiencia del código fuente esta directamente unida a la eficiencia de los algoritmos definidos

durante el diseño detallado. Sin embargo el estilo de codificación puede afectar a la velocidad de ejecución y a los requisitos de memoria. El siguiente conjunto de directrices se debe seguir siempre en el proceso de traducción del diseño detallado al código:

Simplificar las expresiones aritméticas y lógicas antes de convertirlas en código.

Evaluar cuidadosamente los bucles anidados para determinar si se pueden sacar fuera de ellos algunas sentencias o expresiones.

Cuando sea posible, evitar el uso de arrays multidimensionales.

Cuando sea posible, evitar el uso de punteros y listas complejas.

Usar "rápidas" operaciones aritméticas.

No mezclar tipos de datos, incluso aunque el lenguaje lo permita.

Usar, cuando sea posible, aritmética entera y expresiones lógicas.

Muchos compiladores incluyen opciones de optimización que generan automáticamente código eficiente al colapsar expresiones repetitivas, evaluar los bucles, usar aritmética rápida y aplicar otros algoritmos relacionados con la eficiencia. Para las aplicaciones en las que la eficiencia sea vital, tales compiladores son una herramienta de codificación fundamental.

Eficiencia En Memoria

Para la eficiencia en memoria se debe tener en cuenta las posibilidades de "paginación" del

sistema operativo. La localización o el mantenimiento del código en un campo funcional mediante construcciones estructuradas es un método excelente para reducir la paginación y, por tanto, incrementar la eficiencia.

A diferencia de otras características de los sistemas que se encuentran enfrentadas unas con otras, las técnicas para conseguir una eficiencia en tiempo de ejecución pueden llevar a veces a una eficiencia en memoria. Por ejemplo al limitar el uso de arrays tri o tetradimensionales, se

http://www.duiops.net/windows/articulos/desde23.htm

http://www.webestilo.com/php/php05b.phtml

obtienen sencillos algoritmos de acceso a los elementos que son más rápidos y más cortos. De nuevo, la clave para la eficiencia en memoria es "mantenerlo simple".

Eficiencia en la entrada/salida

Cuando se habla de eficiencia se han de considerar dos clases de E/S:

E/S dirigida a la persona. La entrada suministrada por un usuario y la salida producida para un usuario son eficientes cuando la información se puede suministrar o se puede comprender con el mínimo esfuerzo intelectual.

E/S dirigida a otro dispositivo (por ejem. Un disco u otra computadora). La eficiencia de la E/S dirigida a otro hardware es un punto extremadamente complicado. Desde el punto de vista de la codificación (y del diseño detallado), sin embargo, se pueden establecer algunas sencillas directrices para mejorar la eficiencia en la E/S:

Debe minimizarse el numero de peticiones de E/S

Toda la E/S debe ser tratada con buffer para reducir el embotellamiento en la comunicación.

Para las memorias secundarias, se debe seleccionar y usar el método de acceso más simple dentro de los aceptables.

La E/S a dispositivos de memoria secundaria debe hacerse por bloques.

La E/S a terminales e impresoras debe tener en cuenta las posibilidades del dispositivo que puedan afectar a la calidad o a la velocidad.

Recuerde que la "supe eficiencia" en la E/S no merece la pena si no le puede comprender.

El diseño de la E/S establece el estilo y, posteriormente, dicta la eficiencia.


o Explique que es la eficiencia. o A que se refiere la eficiencia en memoria. o Cuales son las dos clases de E/S que se deben considerar cuando se habla de

eficiencia. Explique cada una de ellas.


o ¿Cuáles son las directrices para mejorar la eficiencia en la E/S? o ¿Por qué la entrada/salida a dispositivos de memoria secundaria debe hacerse por

bloques? o ¿Cuál es el conjunto de directrices a seguir en el proceso de traducción del diseño

detallado al código?



Autoevaluación

1. ¿Qué es la eficiencia? 2. ¿Qué es la eficiencia en código. 3. ¿Qué abarca la eficiencia?

MODULO 6

PRUEBAS E IMPLANTACION DE SISTEMAS

Objetivo.

Introducir las técnicas que se pueden utilizar para probar programas y descubrir sus fallas para que sea operacional.

Justificación.

El desarrollo de sistemas de software implica una serie de actividades de software también implica una serie de actividades de producción en las que las posibilidades de que aparezca un fallo humano son enormes. En el diseño de pruebas saldrán a la luz estos errores.

Introducción.

La prueba de software es un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones del diseño y la codificación. Es necesario diseñar pruebas de software que sistemáticamente saquen a la luz diferentes clases de errores para asegurar que el sistema es operacional y luego involucrar a los usuarios bien capacitados en su operación.

DISEÑO Y EJECUCIÓN DE PRUEBAS DE SOFTWARE

EL PROCESO DE PRUEBA

Las pruebas se realizan a lo largo del desarrollo del sistema y no simplemente al final. Esto significa sacar a la luz problemas no conocidos y no demostrar la perfección de programas manuales o equipo.

Aunque el probar es aburrido, es una serie esencial de pasos que ayuda a asegurar la calidad del sistema eventual. La prueba se realiza en subsistemas o módulos de programa conforme el trabajo avanza. La prueba se hace en muchos niveles diferentes y a diversos intervalos. Antes de que el sistema sea puesto en producción, todos los programas deben ser probados en el escritorio, revisados con datos de prueba y revisados para ver si los módulos los trabajan juntos entre ellos, tal como se planeo.

También debe ser probado el sistema trabajando con un todo. Esto incluye probar las interfaces entre subsistemas, la corrección de la salida y la utilidad y comprensibilidad de la documentación de la salida del sistema. Los programadores, analistas, operadores y usuarios juegan papeles diferentes en los diversos aspectos de la prueba

PRUEBA DE PROGRAMAS CON DATOS DE PRUEBA. En esta etapa, los programadores primero probaran sus programas en escritorio para verificar la forma en que el sistema trabajará. En la prueba de escritorio el programador sigue cada paso del programa en papel para revisar si la rutina trabaja como fue escrita.

Luego los programadores deben crear datos de prueba válidos e inválidos. Luego, estos datos son ejecutados para ver si trabajan las rutinas básicas y también para atrapar errores. Si la salida de los módulos principales es satisfactoria, se pueden añadir mas datos de prueba para revisar otros módulos. Los datos de prueba creados deben probar los valores mínimo y máximo posibles, así como también todas las variaciones posibles de formatos y códigos. Se debe revisar cuidadosamente se debe revisar cuidadosamente los archivos de salida de los datos de prueba. Nunca se debe suponer que los datos contenidos en un archivo son correctos simplemente debido a que el archivo fue creado y accesado.

A lo largo de este proceso el analista de sistemas revisa la salida buscando errores, dando consejos al programador sobre cualquier corrección necesaria. Por lo general, el analista recomendara o creará datos de prueba para la prueba de programas, pero puede resaltar al programador omisiones de tipos de datos que deban ser añadidos en pruebas posteriores.

PRUEBA DE ENLACE CON DATOS DE PRUEBA. También se le conoce como prueba en cadena. La prueba de enlace revisa para ver si los programas que son interdependientes trabajan, de hecho, como se planeo.

Una pequeña cantidad de datos de prueba, para probar las especificaciones del sistema, así como los programas, se usan para la prueba de enlace. La prueba de todas las combinaciones puede llevarse varios pasos a través del sistema, debido a que es mucho muy difícil describir los problemas si se trata de probar todo en una sola vez.

El analista crea datos de prueba especiales que cubren una diversidad de situaciones de procesamiento para la prueba de enlace. Primero, se procesan datos de prueba típicos para ver si el sistema puede trabajar las transacciones normales, aquellas que conformarán la mayor parte de su carga. Si el sistema trabaja con las transacciones normales, luego se añaden variaciones, incluyendo los datos inválidos usados para asegurarse de que el sistema pueda detectar errores adecuadamente.

PRUEBA COMPLETA DEL SISTEMA CON DATOS DE PRUEBA. En esta etapa, los operadores y usuarios finales llegan a estar activamente involucrados en la prueba. Se usan datos de prueba creado por el equipo de análisis de sistemas para el propósito específico de probar los objetivos del sistema.

Factores a considerar cuando se prueba el sistema con datos de prueba:

1. Examinar si los operadores tienen documentación adecuada en los manuales de procedimientos para lograr la operación correcta y eficiente.

2. Revisar si los manuales de procedimientos son lo suficientemente claros para comunicar como deben ser preparados los datos para su entrada.

3. Asegurarse si el flujo de trabajo que necesita el sistema nuevo o modificado de hecho fluye.

4. Determinar si la salida es correcta y si los usuarios comprenden que esta es, en todos los sentidos, la forma en que la salida se vera en su forma final.

Esta prueba incluye la reafirmación de los estándares de calidad para el desempeño del sistema, que fueron puestos cuando se establecieron las especificaciones iniciales del sistema. Todos los involucrados deben nuevamente estar de acuerdo con la manera de determinar si el sistema esta haciendo lo que se supone que debe hacer. Esto incluirá mediciones de error, oportunidad, facilidad de uso, ordenamiento adecuado de transacciones, aceptable tiempo caído, manuales de procedimientos comprensibles, etc.

PRUEBA COMPLETA DEL SISTEMA CON DATOS REALES. Este paso permite una comparación precisa de la salida del nuevo sistema con a que s sabe que es salida correctamente procesada, así como una buena sensación de cómo serán manejados los datos reales.

El de prueba es un periodo importante para valorar como interactúan, de hecho, los usuarios finales y operadores del sistema. No es suficiente entrevistar a los usuarios acerca de cómo están interactuando con el sistema, sino que se les debe observar de primera mano.

Los conceptos de observar son la facilidad de aprendizaje del sistema, el ajuste a factores ergonómicos y la reacción del usuario a la retroalimentación del sistema, incluyendo lo que sucede cuando se recibe un mensaje de error y lo que sucede cuando al usuario se le informa que el sistema esta ejecutando sus comandos. Escuche lo que los usuarios dicen acerca del sistema con relación a cómo lo encuentran. Cualquier problema real debe ser resuelto antes de que el sistema sea puesto en producción, y no sólo superficialmente como ajustes al sistema que los usuarios y operadores "debieran" hacer por sí mismos.

También se necesitan ser probados los manuales de procedimientos. La única forma real de probarlos es hacer que lo usuarios y operadores los usen, de ser preferible durante la prueba completa del sistema con datos reales.

Es difícil comunicar los procedimientos con precisión. Los manuales necesitan estar organizados en formas diferentes para los usuarios que interactuarán con el sistema en innumerable maneras. Demasiada información, o muy poca, será obstáculo para el uso del sistema. El uso de hipertexto para manuales en línea puede ayudar en este aspecto. Considere e incorpore las sugerencias de usuarios y operadores en la versión final de los manuales y en otras formas de documentación.


o ¿Podría una prueba exhaustiva (incluso si fuera posible para pequeños programas? garantizar que un programa es al 100 % correcto?

o Pruebe un manual de usuario (o una ayuda) de una aplicación que utilice frecuentemente. Encuentre al menos un error en la documentación.

o ¿Cuál es la diferencia entre datos de prueba y datos reales?


o Su equipo de análisis de sistemas esta a punto de terminar un sistema para Meecham Feeds. Roger tiene bastante confianza de que los programas que ha escrito para el sistema de inventario de Meecham ejecutarán como se necesitan, debido a que son similares a los que ha hecho anteriormente. el equipo ha estado muy ocupado y quisiera comenzar la prueba de sistemas completos tan pronto sea posible. Esto es lo que han propuesto dos de los miembros y jóvenes del equipo:

a) Saltarse la prueba de escritorio de los programas (debido a que programas similares han sido revisados en otras instalaciones, y Roger esta de acuerdo)

b) Hacer la prueba de enlace con gran cantidad de datos para probar que el sistema trabajará.

c) Hacer pruebas del sistema completo con gran cantidad de datos reales para mostrar que el sistema es funcional.

Responda a cada uno de estos pasos de su calendarización de pruebas de propuesta. Use un párrafo para explicar la respuesta. Proponga un plan de prueba. Divida su plan en una secuencia de pasos detallados.

o De quién es la responsabilidad primario para la prueba de programas de computadora.


Pags. 796- 800, Análisis y diseño de sistemas, Kendall & Kendall, 3ª edición, ed. Pearson educación, 1997.

Autoevaluación

1. ¿Qué es el diseño de prueba? 2. ¿En que consiste la prueba de programas con datos de prueba? 3. ¿En qué consiste la prueba de enlace con datos de prueba? 4. ¿Cuál es la prueba completa del sistema con datos de prueba?

ENFOQUES DE IMPLEMENTACIÓN.

El proceso de primero asegurarse de que el sistema de información sea operacional, y permitir que luego tomen los usuarios control de la operación para su uso y evaluación es llamado implementación. El analista de sistemas tiene varios enfoques para la implementación, que deben ser considerados mas cuando se esta preparando el cambio al nuevo sistema. Estos incluyen darle más poder de cómputo a los usuarios vía un centro de información y/o procesamiento distribuido, capacitación de usuarios, conversiones a partir del sistema antiguo y evaluaciones del nuevo.

El primer enfoque para la implementación se refiere al movimiento del poder de cómputo a usuarios individuales, poniendo un centro de información (IC) o dándole poder de computo y responsabilidad a los grupos a lo largo del negocio con la ayuda de la computación distribuida.

El segundo enfoque la implementación es el uso de diferentes estrategias para el entrenamiento de los usuarios y el personal del centro de información, incluyendo el hablarles en su propio nivel, usando una diversidad de técnicas de entrenamiento y asegurándose de que cada usuario comprenda cualquier papel nuevo que deba desempeñar debido al nuevo sistema de información.

Otro enfoque para la implementación es la selección de una estrategia de conversión. El analista de sistemas necesita ponderar la situación y proponer un plan de conversión que sea adecuado para la organización particular del sistema de información.

El cuarto enfoque para la implementación involucra la evaluación del sistema de información nuevo o modificado o el centro de información. El analista necesita formular mediadas de desempeño con las cuales evaluar al centro de información o al sistema. Las evaluaciones vienen del personal del centro de información, usuarios, administración y los mismos analistas.


Pags. 821, Análisis y diseño de sistemas, Kendall & Kendall, 3ª edición, ed. Pearson educación, 1997.

Autoevaluación

1. ¿A qué se refiere el tercer enfoque de la implementación? 2. ¿Qué es la implementación? 3. ¿Cuáles son los cuatro enfoques de implementación?

CAPACITACIÓN A USUARIOS.

Los analistas de sistemas se involucran en un proceso educacional con los usuarios que es llamado capacitación. A lo largo del ciclo de vida de desarrollo de sistemas los usuarios han estado involucrados, por lo que ahora el analista debe poseer una valoración adecuada de los usuarios que deben ser capacitados. Tal como hemos visto, los centros de información mantienen instructores propios.

En la implementación de grandes proyectos, el analista estafa frecuentemente analizando la capacitación en vez de estar personalmente involucrado en él. Uno de los valores más preciados que puede dar el analista a cualquier situación de capacitación es la capacidad de ver el sistema desde el punto de vista del usuario. El analista nunca debe olvidar qué es el enfrentar un nuevo sistema. Estos recuerdos pueden ayudar a que el analista empatice con os usuarios y facilite su capacitación.

ESTRATEGIAS DE CAPACITACIÓN.

Las estrategias de capacitación son determinadas por quien esta siendo capacitación y quien lo capacitara. El analista querrá asegurarse de que cualquiera cuyo trabajo este afectado por el nuevo sistema de información esté capacitado adecuadamente por el instructor adecuado.

A quien capacitar. Todas las personas que tendrán uso primario o secundario del sistema deben ser capacitadas. Esto incluye a todos, desde el personal de captura de datos hasta aquellos que usaran la salida para tomar decisiones sin usar personalmente una computadora. La cantidad de capacitación que requiere un sistema depende, por lo tanto, de qué tanto cambiara el trabajo de alguien debido al nuevo sistema.

Hay que asegurarse de que estén separados usuarios de diferentes niveles de habilidades e intereses de trabajo. Es ciertamente problemático incluir novatos en las mismas sesiones de capacitación con los expertos, debido a que los novatos se pierden rápidamente y los expertos rápidamente se aburren con los puntos básicos. Ambos grupos quedan perdidos.

Las personas capacitaran a los usuarios. Para un proyecto grande, se pueden usar muchos instructores diferentes, dependiendo de que tantos usuarios deben ser capacitados y quienes son. Las fuentes de capacitación posibles incluyen:

Vendedores.

1. Analistas de sistemas. 2. Instructores pagados externamente. 3. Instructores en casa. 4. Otros usuarios del sistema.

Esta lista da solamente unas cuantas de las operaciones que tiene el analista para planear y proporcionar la capacitación.

Los grandes vendedores frecuentemente proporcionan capacitación gratuita fuera de sitio y de uno o dos días en sus instalaciones. Estas sesiones incluyen tanto conversación como capacitación practica en un ambiente enfocado.

Debido a que los analistas de sistemas conocen al personal de la organización y al sistema, frecuentemente pueden proporcionar buena capacitación. El uso de analistas con objeto de capacitar depende de su disponibilidad, debido a que también se espera que supervisen todo el proceso de implementación.

Los instructores pagados externamente a veces son llamados a la organización para que ayuden con la capacitación. Pueden tener amplia experiencia en enseñar a la gente como usar una diversidad de computadoras, pero tal vez no den la capacitación practica necesario para algunos

usuarios. Además, tal vez no sean capaces de personalizar sus presentaciones lo suficiente para hacerlas significativas a los usuarios.

Los instructores de casa de tiempo completo están, por lo general, familiarizados con el personal y pueden adecuar los materiales a sus necesidades. Una de las desventajas de los instructores de casa es que pueden poseer experiencia en otras áreas, pero no en sistemas de información, y tal vez les falte, por lo tanto, la profundidad que necesitan lo usuarios.

También es posible hacer que cualquiera de esos instructores capaciten a un pequeño grupo de personas de cada área funcional que usara el nuevo sistema de información. Ellos a su vez pueden ser requeridos para que capaciten a los usuarios restantes. Este enfoque puede trabajar bien si los capacitados originalmente todavía tienen acceso a los materiales e instructores como recursos cuando están ellos mismos proporcionando la capacitación. En caos contrario, puede degenerar en una situación de prueba y error, en vez de una estructurada.

LINEAMIENTOS PARA LA CAPACITACIÓN.

El analista tiene cuatro lineamientos principales para ajustar una capacitación. Son:

1. Establecimiento de objetivos mensurables. 2. Uso de métodos de capacitación adecuados. 3. Selección de lugares de capacitación adecuados. 4. Empleo de materiales de capacitación comprensibles.

Objetivos de capacitación. Quien esté siendo entrenado dicta, en gran parte, los objetivos de la capacitación. Los objetivos del entrenamiento para cada grupo deben ser indicados claramente. Los objetivos bien definidos son de una gran ayuda para permitir que los capacitados sepan lo que se espera de ellos. Además, los objetivos permiten la evaluación de la capacitación cuando ha terminado. Por ejemplo, los operadores deben saber cosas básicas, tales como el encendido de la maquina, que hacer cuando suceden los errores comunes, búsqueda de fallas básicas y como terminar una captura.

Métodos de capacitación. Cada usuario y operador necesitara una capacitación ligeramente diferente. Hasta cierto punto, sus trabajos determinan lo que necesitan saber, y su personalidad, experiencia y conocimientos de fondo determinan cómo aprender mejor. Algunos usuarios aprenden mejor viendo, otros oyendo y otros haciendo. Debido a que, por lo general, no es posible personalizar la capacitación para un individuo, frecuentemente la mejor manera de proceder es con una combinación de los métodos. De esta forma se llega a la mayoría de los usuarios por medio de un método u otro.

Los métodos para aquellos que aprenden mejor viendo incluyen demostraciones del equipo y exposiciones a los manuales de entrenamiento. Aquellos que aprenden mejor oyendo se beneficiaran de platicas acerca de los procedimientos, discusiones y sesiones de preguntas y respuestas entre los instructores y capacitados. Aquellos que aprenden mejor haciendo necesitan experiencia práctica con el nuevo equipo. Para trabajos como el del operador de computadora, la experiencia practica es esencial y, en cambio, tal vez un gerente de aseguramiento de calidad de una línea de producción pueda solamente necesitar ver la salida, aprender como interpretarla y saber cuándo está programado que llegue.

Lugares de capacitación. La capacitación se realiza en diferentes ubicaciones, algunas de las cuales son más adecuadas para el aprendizaje que otras. Los grandes vendedores de computadoras proporcionan ubicaciones fuera del local donde se mantiene equipo operable libre de costos. Sus instructores proporcionan experiencia práctica, así como seminarios, en un ambiente que permite que los usuarios se concentren en el aprendizaje del nuevo sistema. Una de las desventajas de la capacitación fuera de sitio es que los usuarios están alejados del contexto de la organización dentro de la cual deben existir eventualmente.

La capacitación en sito dentro de la organización de los usuarios también es posible con varios tipos diferentes de instructores. La ventaja es que los usuarios ven el equipo puesto en donde

estará cuando sea completamente operacional. Una desventaja seria es que los capacitados a veces de sienten culpables de no cumplir sus labores de trabajo normales si permanecen en el sitio para la capacitación, por lo tanto, puede ser que no sea posible la concentración completa en la capacitación.

La capacitación fuera de sitio también puede estar disponible por una cuota a través de consultores y vendedores. Estos pueden estar ubicados en lugares donde hay espacio rentado para reuniones, tal como un hotel, o incluso pueden ser instalaciones permanentes mantenidas por los instructores. Estos arreglos permiten que los trabajadores estén libres de las demandas del trabajo normal, pero también puede ser que no proporcionen el equipo para la capacitación práctica.

Materiales de capacitación. Al planear la capacitación de los usuarios, los analistas de sistemas deben darse cuenta de la importancia de materiales, de capacitación bien preparados. Estos incluyen manuales de capacitación, cosos de capacitación, en donde a los usuarios les es asignado trabajo por medio de un caso que incorpora la mayoría de las interacciones comúnmente encontradas con el sistema, uy prototipos y esquemas de la salida. La mayoría del software en paquete proporciona tutoriales en línea para ilustrar las funciones básicas.

Debido a que la comprensión del sistema pro parte del usuario depende de ellos, los materiales de capacitación deben estar escritos con claridad. Esto significa que los materiales de capacitación deben tener buenos índices, estar escritos para la audiencia adecuada con un mínimo de vocabulario especial y disponible para cualquiera que los necesite. En la figura 21.16 se proporciona un resumen de consideración para los objetivos, métodos, lugares y materiales de capacitación.

ELEMENTOS FACTORES RELEVANTES

Objetivos de la capacitación. Métodos de capacitación.

Dependen de los requerimientos del trabajo del usuario. Dependen del trabajo del usuario, personalidad conocimientos y experiencias; use una combinación de pláticas, demostraciones, práctica y estudio.

Sitios de capacitación

Depende de los objetivos de la capacitación, costo, disponibilidad; sitios gratis de vendedor con equipo operable; instalación en casa; instalaciones rentadas

Materiales de capacitación Depende de las necesidades del usuario; manuales de operación, casos, prototipos de equipo y salida; tutoriales en línea.


o Explique con sus palabras que es la implementación o Explique los cuatro enfoques de implementación. o Algunos usuarios aprenden mejor viendo, otros oyendo y todavía otros haciendo.

Dé un ejemplo de cómo puede ser incorporado cada tipo de aprendizaje en una sesión de capacitación.

o Liste los atributos de materiales de capacitación bien realizados para los usuarios.


o Liste las fuentes posibles de capacitación para los usuarios de sistemas de información.

o Balboatrack, el sistema de trenes regional/local, está tratando de capacitar a los usuarios de su sistema de cómputo recientemente instalado. Para que los usuarios obtengan la capacitación adecuada, los analistas de sistemas involucrados con el proyecto envían un memorándum a las cabezas de los cuatro departamentos que incluyen usuarios primarios y secundarios. El memorándum dice en una parte, "solamente las personas que sienten que requieren capacitación necesitan hacer reservaciones para capacitarse fuera de sitio, y todos los demás deberán aprender

el sistema conforme trabajan con él en su trabajo. Solamente tres de los cuarenta posibles usuarios se registraron. Los analistas quedaron satisfechos de que el memorándum efectivamente separó a la gente que necesita capacitación de aquella que no.

a) En un párrafo explique como perdieron el rumbo los analistas de sistema en su enfoque para la capacitación.

b) Esquematice los pasos que usted seguiría para asegurar que las personas correctas de Balboatrack fueron capacitadas.



Autoevaluación

1. ¿Por qué es importante tener objetivos de capacitación bien definidos? 2. ¿Quién debe ser capacitado para usar el sistema de capacitación nuevo o

modificado? 3. Indique una ventaja y una desventaja de las sesiones de capacitación en sitio. 4. ¿Cuáles son los métodos de capacitación? 5. ¿Cuáles son los lugares de capacitación?

SEGURIDAD DEL SISTEMA.

La seguridad de las instalaciones de computación, los datos guardados y la información generada es parte de una conversión satisfactoria.

Es útil pensar sobre la seguridad de los sistemas, datos e información en un continuo imaginario, desde totalmente segura hasta totalmente seguro, las acciones que toman los analistas y los usuarios se pretende que muevan al sistema hacia el lado seguro del continuo, disminuyendo la vulnerabilidad del sistema. Debe hacerse notar que conforme mas gente de la organización obtenga mayor poder de computo, la seguridad llega a ser cada vez más difícil y compleja. A veces las organizaciones contrataran a un consultor de seguridad para que trabaje con el analista de sistemas cuando la seguridad es crucial para las operaciones exitosas.

La seguridad es responsabilidad de todos aquellos que están en contacto con el sistema, y es solo tan buena como el comportamiento o política más laxa en la organización. La seguridad tiene tres aspectos interrelacionados: física, lógica y de comportamiento. Los tres deben trabajar juntos si se pretende que la calidad de la seguridad permanezca alta.

Seguridad física. La seguridad física se refiere a la seguridad de las instalaciones de computación, su equipo y software por medios físicos. Esto puede incluir el control del acceso al cueto de la computadora por medio de gafetes legibles por maquina o sistemas de registro/despedida humanos, el uso de cámaras de televisión de circuito cerrado para monitorear las áreas de computadora y el respaldo de datos frecuente así como el almacenamiento de los respaldos en un área a prueba de fuego y de agua.

Además, el equipo de computo pequeño debe estar asegurado para que un usuario típico no pueda moverlo, y se debe garantizar la corriente sin interrupciones. Las alarmas que notifican a las personas adecuadas la presencia de fuego, inundaciones o intrusión humana no autorizada deben ser funcionales todo el tiempo.

Las decisiones acerca de la seguridad física deben tomarse cuando el analista esta planeando las instalaciones de cómputo y la compra de equipo. Obviamente, la seguridad física puede ser mucho más fuerte si se piensa en ella antes de la instalación actual cuando son construidos, en vez de ser acondicionados posteriormente.

Seguridad lógica. La seguridad lógica se refiere a los controles lógicos dentro del mismo software. Los controles lógicos familiares para la mayoría de los usuarios son contraseñas y códigos de autorización de algún tipo. Cuando son usados permiten que el usuario con la contraseña correcta entre al sistema o a una parte particular de la base de datos.

Sin embargo, las contraseñas son tratadas desdeñosamente en muchas organizaciones. Se ha visto que los empleados gritan una contraseña a través de oficinas con mucha gente, escriben las contraseñas en papeles pegados a sus terminales y comparten contraseñas personales con empleados autorizados que han olvidado la suya.

Los controles lógicos y físicos son importantes, pero claramente no son suficientes para proporcionar una seguridad adecuada. También se necesitan cambios de comportamiento.

Seguridad de comportamiento. Las expectativas de comportamiento de una organización están codificadas en sus manuales de política y hasta en signos puestos en tableros de noticias. Pero el comportamiento que tienen internamente los miembros de la organización también es crítico para el éxito de los esfuerzos de seguridad.

La seguridad puede comenzar por investigar a los empleados que eventualmente tendrán acceso a las computadoras, datos e información, para asegurarse de que sus intereses sean consistentes con los de la organización y que comprenden completamente la importancia de llevar a cabo

procedimientos de seguridad. Las políticas que se refieren a seguridad deben ser escritas, distribuidas y actualizadas por que los empleados estén totalmente conscientes de las expectativas y responsabilidades. Por lo general, aquí es donde el analista de sistemas tendrá contacto por primera vez con los aspectos de comportamiento de la seguridad.

Parte de la faceta de comportamiento de seguridad es monitorear el comportamiento a intervalos irregulares para asegurarse de que se estén siguiendo los procedimientos adecuados y para corregir cualquier comportamiento que los haya erosionado con el tiempo. El hacer que el sistema registre la cantidad de intentos de registro no satisfactorios de los usuarios es una forma de monitorear si usuarios no autorizados están tratando de registrarse en el sistema. El inventario periódico y frecuente de equipo y software es deseable. Además, se deben examinar sesiones extrañamente largas o el acceso después de horas de trabajo no típico al sistema.

La salida generada por el sistema debe ser reconocida por su potencial de poner la organización en riesgo en algunas circunstancias. Los controles de la salida incluyen pantallas que solo pueden ser accesados por medio de contraseñas, clasificación de información (esto es, a quien se le puede distribuir y cuando) y almacenamiento seguro de documentos impresos y almacenados magnéticamente.

En algunos casos se debe hacer provisiones para la destrucción de documentos que son clasificados o propios. Se pueden contratar servicios de destrucción o pulverización de una empresa externa, por una cuota, que destruirán medios magnéticos, cartuchos de maquinas de escribir e impresoras y papel.


o Defina lo que es seguridad o Dé tres ejemplos de seguridad física. o Dé tres ejemplos de seguridad lógica. o De tres ejemplo de seguridad de comportamiento.


o ¿De quién es la responsabilidad de la seguridad del sistema? o ¿Por qué la seguridad física, lógica y de comportamiento deben trabajar juntos?



Autoevaluación

1. ¿Qué es la seguridad? 2. ¿Qué es la seguridad física? 3. ¿Qué es la seguridad lógica? 4. ¿Qué es la seguridad de comportamiento?

MODULO 7

INGENIERIA DEL SOFTWARE ASISTIDA POR COMPUTADORAS(CASE)

MODULO 7. CASE

Objetivo.

Introducir la tecnología CASE y como se pueden utilizar las herramientas CASE para ayudar al proceso del software.

Justificación.

En los últimos años los analistas han comenzado a beneficiarse de nuevas herramientas de productividad que han sido creadas implícitamente para mejorar su trabajo rutinario mediante un apoyo automatizado; a estas herramientas se les llama herramientas CASE.

Introducción.

Las herramientas CASE nos sirven como apoyo para aumentar la productividad, comunicación más efectiva con los usuarios e integar el trabajo que realizan en el sistema, desde el principio hasta el

fin.

CONCEPTO DE CASE.

CASE (Computer Aided Software Engineering) Ingeniería de software Asistida por Computadora. Es un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información.

Las herramientas CASE abarcan todos los pasos del proceso de software, y también aquellas actividades generales que se aplican a lo largo de todo el proceso.

Las herramientas CASE son un complemento de la caja de herramientas del ingeniero del software, además ayudan a asegurar que la calidad sea algo diseñado antes de llegar a construir el producto.

Las herramientas CASE se pueden clasificar por:

Su función.

Su papel como instrumentos para administradores o personal técnico.

Su utilización en los distintos pasos del proceso de ingeniería del Software.

La arquitectura de su entorno (hardware y software) que les presta su apoyo.

Incluso por su origen o su coste.

COMPONENTES DE UN CASE

BLOQUES BASICOS DE CASE

Bloques de construcción CASE, los entornos que tienen éxito para la ingeniería del software una arquitectura de entorno que abarca un hardware adecuado y un software de sistema adecuado.

Las arquitecturas del entorno que constan de una plataforma de hardware y un apoyo de S.O. constituyen los fundamentos de CASE. Pero entorno CASE requiere otros bloques de construcción, existe un conjunto de servicios de portabilidad que proporciona un puente entre las herramientas CASE y su marco de referencia de integración y la arquitectura del

entorno. Los servicios de portabilidad permiten que las herramientas CASE y su marco de referencia de integración migren entre distintas plataformas del hardware y S.O.

Las herramientas CASE que se utilizan en la actualidad no han sido construidos empleando todos los bloques de construcción.

PRINCIPALES CASE DEL MERCADO Y SU USO.

HERRAMIENTAS DE LA INGENIERÍA DE LA INFORMACIÓN.

Estas herramientas CASE modelan la información de negocios cuando ésta se transfiere entre distintas entidades organizativas en el seno de una compañía. El objetivo primordial de las herramientas de esta categoría consiste en representar objetos de datos de negocios, sus relaciones, y ayuda a comprender mejor la forma en que fluyen estos objetos de datos entre distintas zonas de negocio en el seno de la compañía. Estas herramientas proporcionan una ayuda importante cuando se diseñan nuevas estrategias para los sistemas de información y cuando los métodos y sistemas no satisfacen las necesidades de la organización.

MODELADO DE PROCESOS Y HERRAMIENTAS DE ADMINISTRACIÓN.

Se utilizan para representar los elementos clave del proceso de modo que sea posible entenderlo mejor. Estas herramientas también pueden proporcionar vínculos con descripciones de procesos que ayuden a quienes estén implicados en el proceso de comprender las tareas que se requieren para llevar a cabo ese proceso. Las herramientas de administración de procesos pueden proporcionar vínculos con otras herramientas que proporcionen un apoyo para actividades de proceso ya definidas.

HERRAMIENTAS DE PLANIFICACIÓN DE PROYECTOS.

Las herramientas de esta categoría se concentran en dos áreas primordiales:

Estimación de esfuerzos de proyecto y de costes de software. Calculan el esfuerzo estimado, la duración del proyecto y el numero recomendado de personas.

Planificación de proyectos. Capacitan al administrador para definir todas las áreas del proyecto (la estructura de desglose de tareas), para crear una red de tareas (normalmente empleando una entrada gráfica), para representar las interdependencias entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto.

HERRAMIENTAS DE ANÁLISIS DE RIESGOS.

Las herramientas de análisis de riesgos capacitan al administrador el proyecto para construir una tabla de riesgos proporcionando una guía detallada en la identificación y análisis de riesgos.

HERRAMIENTAS DE ADMINISTRACIÓN DE PROYECTOS.

La planificación del proyecto y el plan del proyecto deben seguirse y de monitorizarse de forma continúa. Además, el gestor deberá de utilizar las herramientas que recojan métricas que en la última instancia proporcionen una indicación de la calidad el producto del software. Las herramientas de esta categoría suelen ser extensiones de herramientas de planificación de proyectos.

HERRAMIENTAS DE SEGUIMIENTO DE REQUISISTOS

Cuando se desarrollan grandes sistemas, el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. El objetivo de las herramientas de seguimiento de requisitos es proporcionar un enfoque sistemático para el aislamiento de requisitos, comenzando por las especificaciones del cliente. Las herramientas de trazado de requisitos típicos combinan una evaluación de textos por interacción humana, con un sistema de gestión de bases de datos que

almacena y categoría todos y cada uno de los requisitos del sistema que se "analizan" a partir de las especificaciones originales.

HERRAMIENTAS DE MÉTRICAS Y GESTIÓN.

Las métricas del software mejoran la capacidad del administrador para controlar y coordinar el proceso del software y la capacidad del ingeniero para mejorar la calidad del software que se produce.

Las herramientas métricas actuales se centran en procesos, proyectos y características del producto.

Las herramientas orientadas a la gestión capturan métricas especificas del proyecto (por ejemplo: LDC/personamos, defectos por punto de función) que proporcionan una indicación global de productividad o de calidad. Las herramientas orientadas técnicamente determinan métricas técnicas que proporcionan una mejor visión de la calidad del diseño o del código. Muchas de las herramientas métricas avanzadas mantiene una base de datos de medidas de medias de la industria.

Basándose en características de proyectos y de productos proporcionados por el usuario, estas herramientas califican los números locales frente a los valore medios de la industria (y frente al rendimiento local anterior) y sugieren estrategias para llegar a mejoras. Estas herramientas utilizan un sistema experto para sugerir el orden en el que se debe llevar a cabo un proyecto.

HERRAMIENTAS DE DOCUMENTACIÓN

Las herramientas de producción de documentos y autoedición prestan su apoyo a casi todos los aspectos de la ingeniería del software, y representan una importante oportunidad de aprovechamiento para todos los desarrolladores del software. La mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad de tiempo considerable en el desarrollo de documentos, y en muchos casos el proceso de documentación en si resulta bastante deficiente. No es raro que una organización de desarrollo de software invierta hasta en un 20 o 30 pro ciento de su esfuerzo global de desarrollo de software en la documentación. Por esta razón, las herramientas de documentación suponen una oportunidad importante para mejorar la productividad.

HERRAMIENTAS DE SOFTWARE DE SISTEMA.

CASE es una tecnología de estaciones de trabajo. Por tanto, el entorno CASE debe adaptase a un software de sistema en redes de alta calidad, al correo electrónico, a los boletines electrónicos y a otras capacidades de comunicaciones.

HERRAMIENTAS DE CONTROL DE CALIDAD.

La mayor parte de las herramientas CASE que afirman que tiene como principal interés el control de calidad son en realidad herramientas métricas que hace una auditoria del código fuente para determinar si es justa o no a ciertos estándares del lenguaje. Otras herramientas extraen métricas técnicas como base para medir la calidad del software que se esta construyendo.

HERRAMIENTAS DE GESTIÓN COMO BASE DE DATOS.

El software de gestión de bases de datos sirve como fundamentos para establecer una base de datos CASE. Dado el énfasis acerca de los objetos de configuración, las herramientas de gestión

de bases de datos para CASE pueden evolucionar a partir de los sistemas de gestión de bases de datos relacionales (SGBDR) para transformarse en sistemas de gestión de bases de datos orientadas a objetos (SGBDOO).

HERRAMIENTAS DE CODIFICACIÓN DE CUARTA GENERACIÓN.

Los sistemas de consulta de bases de datos, los generadores de código y los lenguajes de cuarta generación han cambiado la forma en que se desarrollan los sistemas. Idealmente, estas herramientas de generación de código no solo traducen la descripción de un sistema operativo, sino que también ayudan a verificar la corrección de la especificación del sistemas de tal forma que la salida resultante satisfaga los requisitos del usuario.

Los lenguajes de cuarta generación se usan ampliamente en aplicaciones de sistemas de información.

Aunque los lenguajes de cuarta generación, los generadores de código y los generadores de aplicaciones, permiten que un ingeniero de software especifique un sistema a un nivel muy alto de abstracción; cada una de estas herramientas difiere en aspectos importantes.

HERRAMIENTAS DE MANTENIMIENTO

Las herramientas CASE para el mantenimiento de software abarcan una actividad que actualmente ocupa, aproximadamente, el 70% del esfuerzo total dedicado al software. La categoría de herramientas de mantenimiento puede subdividirse de la siguiente forma:

Herramientas de ingeniería inversa a especificaciones. Toman el código fuente como entrada y generan modelos de diseño y análisis estructurado, listas de utilización y otra información con el diseño.

Herramientas de reestructuración y análisis de código. Analizan la sintaxis del programa, generan un grafo de flujo de control y un programa estructurado.

Herramientas interactivas de reingeniería de sistema. Se utilizan para modificar sistemas de base de datos.

Estas herramientas están limitadas a lenguajes de programación específicos y requieren cierto grado de interacción con el ingeniero de software.

HERRAMIENTAS DE GESTIÓN DE CONFIGURACIÓN DE SOFTWARE.

La gestión de configuración de software (GCS) se encuentra en el núcleo de todos los entornos CASE. Las herramientas pueden ofrecer su asistencia en las cinco tareas principales de GCS: identificación, control de versiones control de cambios, auditorias y contabilidad de estados. La base de datos CASE proporciona un mecanismo para identificar todos los elementos de configuración y relacionarlo con otros elementos; un acceso sencillo a los elementos de configuración individuales facilita el proceso de auditoria; las herramientas de comunicación CASE pueden mejorar enormemente la contabilidad de estados (ofreciendo información acerca de los cambios a todos aquellos que necesiten conocerlos).

HERRAMIENTAS DE ANÁLISIS Y DISEÑO.

Las herramientas de análisis y diseño capacitan al ingeniero del software para crear modelos del sistema que haya que construir. Los modelos contienen una representación de los datos, de la función y del comportamiento (en el nivel de análisis), así como caracterizaciones del diseño de datos, arquitectura, procedimientos e interfaz. Al efectuar una comprobación de la consistencia y validez del modelo, las herramientas de análisis y diseño proporcionan al ingeniero del software un cierto grado de visión en lo tocante a la representación del análisis, y le ayudan a eliminar errores antes de que se propaguen al diseño, o lo que es peor, a la propia implementación.

HERRAMIENTAS PRO/SIM.

Las herramientas PRO/SIM (de prototipos y simulación) proporcionan al ingeniero del software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de llegar a construirlo. Además, capacitan al ingeniero del software para desarrollar simulaciones del sistema de tiempo real que permitirán al cliente obtener ideas acerca de su funcionamiento, comportamiento y respuesta antes de la verdadera implementación.

HERRAMIENTAS DE DESARROLLO Y DISEÑO DE INTERFAZ.

Las herramientas de desarrollo y diseño de interfaz son en realidad un conjunto de primitivas de componente de programas tales como menús, botones, estructuras de ventanas, iconos, mecanismos de desplazamiento, controladores de dispositivos, etc., Sin embargo, estos conjuntos de herramientas se están viendo sustituidos por herramientas de generación de prototipos de interfaz que permiten una rápida creación en pantalla de sofisticadas interfaces de usuario, que se ajustan al estándar de interfaz que se haya adoptado para el software.

HERRAMIENTAS DE GENERACIÓN DE PROTOTIPOS.

Se puede utilizar toda una gama de herramientas de generación de prototipos. Los generadores de pantallas permiten al ingeniero de software definir rápidamente la disposición de pantalla para aplicaciones interactivas. Otras herramientas de prototipos CASE mas sofisticadas permiten la creación de un diseño de datos, acoplado con las disposiciones de la pantalla y de los informes simultáneamente. Muchas herramientas de análisis y diseño proporcionan extensiones que ofrecen alguna opción de generación de prototipos. Las herramientas PRO/SIM generan un esqueleto de código fuente en Ada y C para las aplicaciones de ingeniería (en tiempo real). Por ultimo, una gama de herramientas de cuarta generación poseen también características de generación de prototipos.

HERRAMIENTAS DE PROGRAMACIÓN.

La categoría de herramientas de programación abarca los compiladores, editores y depuradores que están disponibles para prestar su apoyo en la mayoría de los lenguajes de programación convencionales. Además, los entornos de programación orientados a objetos (OO), los lenguajes de cuarta generación, los entornos de programación gráfica, los generadores de aplicaciones y los lenguajes de consulta de bases de datos residen también en esta categoría.

HERRAMIENTAS DE INTEGRACIÓN Y COMPROBACIÓN.

En su directorio de herramientas de comprobación de software, software Quality Engineering define las siguientes categorías de herramientas de comprobación:

Adquisición de datos: herramientas que adquieren datos que se utilizaran durante la comprobación.

Medida estática: herramientas que analizan el código fuente sin ejecutar casos de prueba. Medida dinámica: herramientas que analizan el código fuente durante la ejecución. Simulación: herramientas que simulan las funciones del hardware o de otros elementos

externos. Administración de comprobaciones: herramientas que prestan su asistencia en la

planificación, desarrollo y control de las comprobaciones. Herramientas de funcionalidad cruzada: se trata de herramientas que cruzan los limites de

las categorías anteriores.

Debería tenerse en cuenta que muchas de las herramientas de comprobación poseen características que abarcan dos o más de las categorías anteriores.

HERRAMIENTAS DE ANÁLISIS ESTÁTICO.

Las herramientas de análisis estático prestan su asistencia al ingeniero del software a efectos de derivar casos prácticos. Se utilizan tres tipos distintos de herramientas estáticas de comprobación en la industria: herramientas de comprobación basadas en código, lenguajes de comprobación especializados, y herramientas de comprobación basadas en requisitos. Las herramientas de comprobación basadas en código admiten un código fuente (o PDL) como entrada y efectúan un cierto número de análisis que can lugar a la generación de casos de prueba. Los lenguajes de comprobación especializados (por ejemplo: ATLAS) capacitan al ingeniero del software para escribir detalladas especificaciones de comprobación que describirán todos los casos de prueba y la logística de su ejecución. Las herramientas de comprobación basadas en requisitos aíslan

Requisitos específicos del usuario y sugieren casos de prueba (o clases de comprobaciones) que ejerciten estos requisitos.

HERRAMIENTAS DE ANÁLISIS DINÁMICO.

Las herramientas de análisis dinámico interactúan con un programa que se esté ejecutando, comprueban la cobertura de rutas, comprueban las afirmaciones acerca del valor de variables específicas y en general instrumentan el flujo de ejecución del programa. Las herramientas dinámicas pueden ser bien intrusivas, bien no intrusivas. Las herramientas intrusivas modifican el software que hay que comprobar mediante sondas que se insertan (instrucciones adicionales) y que efectúan las actividades mencionadas anteriormente. Las herramientas de comprobación no intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el procesador que contenga el programa que se está comprobando.

HERRAMIENTAS DE GESTIÓN DE COMPROBACIÓN.

Las herramientas de gestión de comprobación se utilizan para comprobar y coordinar la comprobación de software para cada uno de los pasos principales de comprobación. Las herramientas de esta categoría administran y coordinan la comprobación de regresiones, efectúan comparaciones que determinan las diferencia s entre la salida real y la esperada, y efectúan comprobaciones por lotes de programas con interfaces interactivas entre hombre y maquina. Además de las funciones indicadas anteriormente, muchas herramientas de gestión de comprobaciones sirven también como controladores de comprobación genéricos. Un controlador de comprobación lee uno o mas casos de prueba de algún archivo de pruebas, da formato a los datos de prueba para que se ajusten a las necesidades del software que se esta probando, e invoca entonces al software que sea preciso comprobar.

HERRAMIENTAS DE COMPROBACIÓN CLIENTES/SERVIDOR.

El entorno C/S existe unas herramientas de comprobación especializadas que ejerciten la interfaz gráfica de usuario y los requisitos de comunicaciones en red par el cliente y el servidor.

HERRAMIENTAS DE REINGENIERÍA.

La categoría de herramientas de reingeniería se pueden subdividir en las funciones siguientes:

Herramientas de ingeniería inversa para producir especificaciones: se toma el código fuente como entrada y se generan modelos gráficos de análisis y diseño estructurado, listo de utilización y otras informaciones de diseño.

Herramientas de reestructuración y análisis de código: se analiza la sintaxis del programa, se genera una gráfica de control de flujo y se genera automáticamente un programa estructurado.

Herramientas de reingeniería para sistemas en línea: se utilizan para modificar sistemas de bases de datos en línea (por ejemplo: para convertir archivos IDMS o DB2 traduciéndolos a un formato de entidades y relaciones).

Muchas de las herramientas anteriores están limitadas a lenguajes de programación específicos (aun cuando se abarcan la mayoría de los lenguajes principales) y requieren un cierto grado de interacción con un ingeniero del software.

Las herramientas de ingeniería inversa y progresiva de la próxima generación harán un uso mucho mayor de técnicas de inteligencia artificial, aplicando una base de conocimientos que se a especifica del dominio de la aplicación (esto es, un conjunto de reglas de descomposición que se aplicarían a todos los programas de una cierta zona de aplicación tal como el control de fabricación o la aviónica). El componente de inteligencia artificial asistirá en la descomposición y reconstrucción de los sistemas, pero seguirá requiriendo una interacción con un ingeniero de software a lo largo del ciclo de la reingeniería.


o Haga una lista de todas las herramientas de desarrollo de software que utilice. Organícelas de acuerdo con la taxonomía presentada en el tema 7.2

o Describa lo que quiere decir la integración entre herramientas y datos con sus propias palabras. Describa otras actividades humanas en las cuales la integración de un conjunto de herramientas haya proporcionado un mayor beneficio que la utilización de cada una de esas herramientas de forma individual. No utilice ejemplos de computación.

o Existen situaciones en las cuales las herramientas de comprobación dinámicas sean "la única forma posible". De ser así ¿cuáles son?


o Explique con sus palabras que es la ingeniería de software asistida por computadora.

o Busque información de productos acerca de al menos tres herramientas de diseño y análisis.

o Busque información de productos acerca de dos herramientas PRO/SIM.


Pags. 541-546, Ingeniería de software. Un enfoque practico, Roger S. Pressman, 4ª edición, ed. Mc Graw Hill, 1997.

Autoevaluación

1. ¿Qué es CASE? 2. Las herramientas CASE se pueden clasificar por: 3. ¿Cuáles son los bloques construcción CASE? 4. Mencione siete herramientas CASE

BIBLIOGRAFIA

McNamara, Technical Aspects of Data Communication, Digital Press Pressman, Roger S., Ingenierìa del Software. Un enfoque práctico. 3ra. edición. McGraw

Hill, 1992 Boehm, Barry, et al, Cost Models for Future Software Life Cycle Processes:COCOMO 2.0, Pages-Jones, Meilir, The Practical Guide to Structured Systems Design, englewood Cliffs,

N.J. Yourdon Press, 1988

Kendall y Kendall, Análisis y Diseño de Sistemas, 3ra. edición, Prentice Hall, 1997 Yourdon, Ed., Análisis Estructurado Moderno, Prentice Hall, 1991 Colleman, The Fusion Method, Prentice Hall, 1996. Rumbaugh, James y otros, Modelado y Diseño Orientado a Objetos, Metodología OMT,

Prentice Hall, 1996. Graham, lan Métodos Orientados a Objetos, Addison Wesley, 2da. De 1996. Booch, Grady, Diseño Orientado a Objetos con Aplicaciones, Adision Wesley, 1996 Sommerville, Ian, Software Engineering, 6th Edición addison Wesley, 1996. Ward, p. Y Mellor, S, Structured Development for Real Time Systems, Yourdon Press,

1986. Capers, Jones, Programming Productivity, McGraw Hill, 1985

Fundamentos de Ingeniería de software · PDF filedesea el cliente, y trabajará...

Documents

Transcript of Fundamentos de Ingeniería de software · PDF filedesea el cliente, y trabajará...