Ingenieria del Software by Olga Patricia Vásquez

Vicerrectoría Académica Proyecto P.A.V. Plataforma de Aprendizaje Virtual

MÓDULO VIRTUAL INGENIERÍA DEL SOFTWARE

MANUEL BLANCO PALENCIA

VICERRECTORÍA ACADÉMICA PROYECTO P.A.V. PLATAFORMA DE APRENDIZAJE VIRTUAL

TECNOLÓGICO DE ANTIOQUIA INSTITUCIÓN UNIVERSITARIA MEDELLÍN 2008

Realización

Vicerrector Académico John Harvey Garavito Londoño Docente (Autor) Manuel Blanco Palencia Equipo Técnico P.A.V. Nubia Amparo Giraldo García Jhonatan Arroyave Jaramillo Giselle Andrea Tamayo Mármol

Tecnológico de Antioquia Institución Universitaria Plataforma de Aprendizaje Virtual Proyecto P.A.V. 2008

Unidad 1

Ingeniería de Sistemas de Computadora La ingeniería de sistemas de computadora es el primer paso en la evolución de un producto nuevo. En el análisis de un sistema es el ingeniero de software quien identifica las necesidades del cliente, determina la viabilidad económica y técnica y, asigna las funciones y el rendimiento al software, al hardware, a la gente y la base de datos. La tarea de ingeniería de sistemas culmina con la creación de la especificación del sistema, (documento base de todo el trabajo de ingeniería). La ingeniería de software requiere de una comunicación intensa entre el cliente y el analista. El cliente debe comprender los objetivos del sistema y ser capaz de exponerlo claramente. El analista debe saber que preguntas hacer, que consejos dar y que investigación llevar a cabo, si la comunicación se rompe en esta fase, el éxito del proyecto está en peligro.

Ingeniería de Sistemas por Computadora

1.1. Ingeniería De Sistemas De Computadora “Hace cuatrocientos cincuenta años, Maquiavelo dijo; “…no hay nada más difícil de conseguir, más arriesgado de mantener ni más inseguro de tener éxito, que estar a la cabeza en la introducción de un nuevo orden de cosas…” Durante el último cuarto del siglo veinte, los sistemas basados en computadora están introduciendo un nuevo orden de cosas. Aunque la tecnología ha hecho grandes avances desde Maquiavelo, sus palabras siguen siendo ciertas. La ingeniería del software y la ingeniería del hardware entran dentro de la amplia categoría que llaman o llamaremos ingeniería de sistemas de computadora. Cada una de estas disciplinas representa un intento de establecer un orden en el desarrollo de sistemas basados en computadora. Las técnicas de ingeniería para el hardware de computadoras provienen del diseño electrónico y han alcanzado un estado de relativa madurez. Las técnicas de diseño de hardware están bien establecidas, los métodos de fabricación mejoran continuamente y la fiabilidad es más una expectativa real que una modesta esperanza. Desafortunadamente, el software de las computadoras todavía padece la descripción Maquiavélica anteriormente descrita. En los sistemas basados en computadora, el software ha reemplazado al hardware en el sentido de ser el elemento del sistema más difícil de planificar, con menos posibilidad de éxito (en tiempo y en dinero) y más peligroso de manejar”. Ingeniería del Software. Roger S. Pressman, pg. 139

1.2. Historia De Ingeniería De Software Durante los primeros años de la informática, el software se consideraba como un añadido. La programación era un "arte", para el que no existían metodologías, era un proceso que se realizaba sin ninguna planificación. En esta época toda la programación se desarrollaba a medida para cada aplicación, y en consecuencia tenía muy poca difusión, habitualmente quien lo escribía era porque lo necesitaba, y era quien lo mantenía.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

En una segunda época (a partir de mitad de la década de 1960) se estableció el software como producto y aparecieron las empresas dedicadas al desarrollo y distribución masiva del mismo. El origen del término Ingeniería del Software, se atribuye a dos conferencias organizadas por la OTAN en 1967 y 1968. La tercera era comenzó a mediados de la década de 1970, época informáticos aumentaron mucho en su complejidad, y nacieron las Esto supuso mucha presión para los desarrolladores, aunque los personal, apenas estaban difundidos. Esta época acabó con microprocesadores.

en la que los sistemas redes de ordenadores. ordenadores para uso la aparición de los

La cuarta era de la evolución de los sistemas informáticos, comienza hacia 1990 y se dirige al impacto colectivo de los ordenadores y el software, en todos los entornos. La industria del software tiene un gran peso en la economía mundial. Aparecen las técnicas de redes neuronales, junto con la lógica difusa.

1.2.1. El software en la actualidad Hoy en día el software tiene un doble papel. Es un producto, pero simultáneamente es el vehículo para hacer entrega de un producto. Como producto permite el uso del hardware, ya sea, por ejemplo, un ordenador personal, un teléfono celular móvil. Como vehículo utilizado para hacer entrega del producto, actúa como base de control, por ejemplo un sistema operativo, o un sistema gestor de redes. El software hace entrega de lo que se considera como el producto más importante del siglo veintiuno, la información. El software transforma datos personales para que sean más útiles en un entorno local, gestiona información comercial para mejorar la competitividad, proporciona el acceso a redes a nivel mundial, y ofrece el medio de adquirir información en todas sus formas. Actualmente se considera la Ingeniería del Software como una nueva área de la ingeniería, y la profesión de ingeniero informático es una de las más demandadas. La palabra ingeniería tiene una connotación de prestigio que provoca que muchas ramas del conocimiento tiendan a autodenominarse así. La ingeniería del software trata áreas muy diversas de la informática y de las ciencias de la computación, aplicables a un amplio espectro de campos, tales como negocios, investigación científica, medicina, producción, logística, banca, meteorología, derecho, redes, entre otras muchas. Sin embargo, es frecuente que en la práctica diaria profesional no se incluya prácticamente ninguna de las recomendaciones más elementales de la ingeniería del software. Es habitual que el desarrollo de software se parezca más al descontrol del cuento de «si los programadores fueran albañiles...» que a una idílica y bien organizada "factoría de software" (concepto de gran vigencia a finales de los ochenta). De hecho, las evaluaciones de los procesos productivos de software realizadas a raíz de los modelos de procesos de software confirman que el desarrollo de software suele estar

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

básicamente en estado caótico. Y no sólo en pequeñas empresas de países como España, sino en grandes proyectos en naciones como EE. UU. y Japón. Como ejemplo de que la ingeniería del software es en la actualidad imprescindible, la revista satírica inglesa Private Eye dio detalles sobre importantes proyectos de software que han dado resultados malos. Entre ellos destacan los del servicio de ambulancias Asinfor de Londres, el servicio de sanidad regional de Wessex, la Sociedad para los derechos de autor y el sistema de manejo de equipajes del aeropuerto de Denver

1.3. OBJETIVOS DE LA INGENIERÍA DE SOFTWARE En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la Ingeniería de Software que busca cumplir con los siguientes objetivos: Mejorar la calidad de los productos de software Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente. Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado. Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: "Las cinco C"

1.3.1. CAPACIDAD Las actividades de la organización están influenciadas por la capacidad de ésta para procesar transacciones con rapidez y eficiencia. Los sistemas de información mejoran esta capacidad en tres formas. Aumentan la velocidad de procesamiento: Los sistemas basados en computadora pueden ser de ayuda para eliminar la necesidad de cálculos tediosos y comparaciones repetitivas. Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento acelerado. Aumento en el volumen: La incapacidad para mantener el ritmo de procesamiento no significa el abandono de los procedimientos existentes. Quizá éstos resulten inadecuados para satisfacer las demandas

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la introducción de procesamiento computarizado, si el sistema existente es manual. Es poco probable que únicamente el aumento de la velocidad sea la respuesta. El tiempo de procesamiento por transacción aumenta si se considera la cantidad de actividades comerciales de la empresa junto con su patrón de crecimiento. Recuperación más rápida de la información: Las organizaciones almacenan grandes cantidades datos por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los necesita. Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rápida la información.

1.3.2. COSTO Vigilancia de los costos: Para determinar si la compañía evoluciona en la forma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales. La creciente competitividad del mercado crea la necesidad de mejores métodos para seguir los costos y relacionarlos con la productividad individual y organizacional. Reducción de costos: Los diseños de sistemas ayudan a disminuir los costos, ya que toma ventaja de las capacidades de cálculo automático y de recuperación de datos que están incluidos en procedimientos de programas en computadora. Muchas tareas son realizadas por programas de cómputo, lo cual deja un número muy reducido de éstas para su ejecución manual, disminuyendo al personal.

1.3.3. CONTROL Mayor seguridad de la información: Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para su lectura por medio de una máquina, es una seguridad difícil de alcanzar en un medio ambiente donde no existen computadoras. Para aumentar la seguridad, generalmente, se desarrollan sistemas de información automatizados. El acceso a la información puede estar controlado por un complejo sistemas de contraseñas, limitado a ciertas áreas o personal, si está bien protegido, es difícil de acceder. Menor margen de error: (mejora de la exactitud y la consistencia)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y con exactitud; por otra parte se efectúan todos los pasos para cada lote de transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefónicas, ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no se produzcan errores.

1.3.4. COMUNICACIÓN La falta de comunicación es una fuente común de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de información bien desarrollados amplían la comunicación y facilitan la integración de funciones individuales. Interconexión: (aumento en la comunicación) Muchas empresas aumentan sus vías de comunicación por medio del desarrollo de redes para este fin, dichas vías abarcan todo el país y les permiten acelerar el flujo de información dentro de sus oficinas y otras instalaciones que no se encuentran en la misma localidad. Una de las características más importantes de los sistemas de información para oficinas es la transmisión electrónica de información, como por ejemplo, los mensajes y los documentos. Integración de áreas en las empresas: Con frecuencia las actividades de las empresas abarcan varias áreas de la organización, la información que surge en un área se necesita en otra área, por ejemplo. Los sistemas de información ayudan a comunicar los detalles del diseño a los diferentes grupos, el estrés y el nivel de costos a partir de detalles proporcionados por otros grupos mantienen las especificaciones esenciales en un sitio de fácil acceso y calculan factores tales como la competitividad

1.3.5. COMPETIVIDAD Los sistemas de información computacionales son un arma estratégica, capaz de cambiar la forma en que la compañía compite en el mercado, en consecuencia éstos sistemas mejoran la organización y la ayudan a ganar "ventaja competitiva", sin embargo, si los competidores de la compañía tienen capacidades más avanzadas para el procesamiento de información, entonces, los sistemas de información pueden convertirse en una "desventaja competitiva". Una organización puede ganar ventaja competitiva a través de sus sistemas de información de diferentes formas:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Asegurar clientes: Como los clientes son lo más importante para una organización, los directivos buscan diferentes formas para conseguir nuevos clientes y mantener los que tienen. Para eso las empresas proporcionan: 1. Mejores precios 2. Servicios exclusivos. 3. Productos diferentes. La ventaja en precios se observa continuamente en la actividad comercial (sí el producto es exclusivo o distinto, entonces, tener el liderazgo en precios bajos quizás no sea el objetivo a alcanzar). La estrategia eficaz de precios, a menudo, se alcanza al desarrollar sistemas de información por razones tales como reducción de costos y ganancia en la exactitud. Generalmente cuando una compañía puede ofrecer servicios exclusivos y atraer clientes, es posible que los competidores no sean capaces de atraer a los clientes de la compañía. Dejar fuera a los competidores: Pasar sobre los competidores puede ser un inconveniente si ellos se encuentran la forma para duplicar los logros de la compañía, los sistemas de información pueden ser la base para dejar fuera del mercado a la competencia ya sea el disuadir sus intentos por ingresar al mercado o creándoles obstáculo para su entrada. Mejores acuerdos con los proveedores: En los negocios, los proveedores también tienen importancia estratégica. Una manera de utilizar los sistemas de información para favorecer arreglos con los proveedores es ofreciendo un mejor precio, disminuyendo los costos. Formar bases para nuevos productos Los sistemas de información también forman la base de muchos productos y servicios nuevos. Los servicios de base de datos experimentan un crecimiento común en todas las industrias. Productos que van desde programas personales hasta planes de construcción pueden hacerse a la medida del cliente gracias al procesamiento de información. Una cosa es clara, es necesario que los sistemas entren en operación y que trabajen de manera confiable.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Por último, es importante tener en cuenta que los sistemas de información basados en computadoras sirven para diversas finalidades que van desde el procesamiento de las transacciones de una empresa hasta proveer de la información necesaria para decidir sobre asuntos que se presentan con frecuencia. En algunos casos los factores que deben considerarse en un proyecto de sistemas de información, como el aspecto más apropiado de la computadora o la tecnología de comunicaciones que se va a utilizar, el impacto del nuevo sistema sobre los empleados de la empresa y las características específicas que el sistema debe tener, se pueden determinar de manera secuencial. Todas estas situaciones están determinadas por tres métodos básicos: 1. Ciclo de vida 2. Desarrollo por análisis estructurado o orientado a objeto 3. Desarrollo por prototipos HISTORIA DE LA INGENIERIA DEL SOFTWARE. Tomado de internet el 29 de agosto de 2008. Hora 11:20 p.m. http://www.um.es/docencia/barzana/IAGP/IAGP2-Ingenieria-software-introduccion.html OBJETIVOS DE LA INGENIERIA DEL SOFTWARE. Tomado de internet el 16 de junio de 2007. Hora 11:00 am. http://www.monografias.com/trabajos5/inso/inso.shtml#obje

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2. Sistemas Basados en Computadora 2.1. Sistemas Basados En Computadora La palabra "Sistema” se ha utilizado en muchas ocasiones y es el termino del que más se ha abusado en el léxico técnico. Hablamos de sistemas políticos, educativos y legislativos, de sistemas bancarios y financieros, de sistemas de transporte. La palabra nos dice poco. Usamos el adjetivo que la describe para comprender el contexto en el que se usa. El diccionario Webster la describe así: Un sistema es un conjunto de componentes que interactúan para alcanzar algún objetivo. Un conjunto u ordenación de cosas relacionadas de tal manera que forman una unidad o un todo orgánico. Un conjunto de hechos, principios, reglas, etc.… clasificados y ordenados de tal manera que muestren un plan lógico uniendo las diferentes partes. Un método o plan de clasificación u ordenación. Una forma establecida de hacer algo; un método; un procedimiento… El diccionario contiene seis definiciones pero no cita ningún sinónimo. “Sistema” es una palabra especial. Teniendo en cuenta la definición anterior hecha por el diccionario Webster, se podría definir un sistema basado en computadora como: Un conjunto u ordenación de elementos organizados para llevar a cabo algún método, procedimiento o control mediante el procesamiento de información.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Software: los programas de computadora, las estructuras de datos y la documentación asociada, que sirven para realizar el método lógico, procedimiento o control requerido. Hardware: los dispositivos electrónicos (p. ej.: CPU (Unidad Central de Procesamiento), memoria) que proporcionan la capacidad de computación y los dispositivos electromecánicos (p. ej.: sensores, motores, bombas) que proporcionan las funciones del mundo exterior. Gente: los individuos que son usuarios y operadores del software y del hardware. Bases de datos: Una colección grande y organizada de información a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema. Documentación: los manuales, los impresos y otra información descriptiva que explica el uso o la operación del sistema. Procedimientos: los pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. Los elementos se combinan de muchas maneras para transformar la información. Por ejemplo, un robot transforma un archivo de órdenes, que contiene instrucciones concretas, en un conjunto de señales de control que producen alguna acción física concreta. El papel del ingeniero de sistemas (o analista de sistemas) es el de definir los elementos de un sistema basado en computadora especifico dentro del contexto de toda la jerarquía de sistemas.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2.2. Características de los Sistemas Los sistemas para cumplir sus propósitos, interactúan con sus medios ambientes. Los sistemas que interactúan con sus medios ambientes reciben entrada y producen salida, sistemas abiertos, en contraste con los sistemas que no interactúan con sus alrededores y se conocen como, sistemas cerrados; todos los sistemas en marcha son abiertos; los sistemas cerrados solo existen en forma conceptual. También los sistemas de computadora son fundamentales en los Sistemas de negocios, en los que podemos destacar: La ingeniería de procesos de negocios: es un enfoque de la ingeniería de sistemas mediante el cual se definen arquitecturas que permitan a un negocio utilizar la información de manera eficaz. Arquitecturas que define la ingeniería de procesos de negocios: arquitectura de datos, una arquitectura de aplicación y una infraestructura de tecnología comprensibles que satisfagan las necesidades de la estrategia de negocios y los objetivos y metas de cada área del negocio. La ingeniería de producto: El ingeniero de sistemas identifica las necesidades del cliente, determina la factibilidad económica y técnica, y asigna funciones y rendimientos al software, al hardware, a las personas y a las bases de datos; es decir a los componentes clave de la ingeniería. Ingeniería de componentes del sistema: es en realidad un conjunto de actividades concurrentes que dirige por separado cada uno de los componentes del sistema: ingeniería del software, ingeniería del hardware, ingeniería humana e ingeniería de bases de datos

2.2.1. Sistemas de información para los negocios De hecho la empresa es un sistema, por tanto los sistemas de información son como cualquier otro sistema de una Organización o Empresa en cuento que tienen propósitos e interactúan con otros componentes de la compañía. La tarea básica de los sistemas de información consiste en procesar la entrada, mantener archivos de datos en relación con la empresa y producir información, informes y otras salidas. Los sistemas de información están integrados por módulos que incluyen el hardware, software y bases de datos. El conjunto particular de módulos, es decir programas, base de datos y procedimientos comprenden una aplicación de sistema de información. Por lo que, los sistemas de información pueden tener aplicaciones de Facturación, Inventario, compras o contabilidad. Dado a que los sistemas de información dan apoyo a otros sistemas de la empresa, los analistas primero que todo deben estudiar el sistema de la organización como un todo y a continuación los detalles de los sistemas de información.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Análisis del Sistema 3.1. Ingeniería De Sistemas De Computadora La ingeniería de sistemas de computadora es una actividad de resolución de problemas. Las funciones que se desean para el sistema son descubiertas, analizadas y asignadas a elementos individuales del sistema. El analista de sistemas en algunos ámbitos de información parte de los objetivos y de las restricciones definidas por el usuario y desarrolla una representación de la función, del rendimiento, de las interfaces, de las restricciones de diseño y de la estructura de la información. La mayoría de los sistemas comienza con un concepto más bien borroso de la función deseada. De esa manera, el analista de sistemas debe delimitar el sistema, identificando el ámbito del funcionamiento y el rendimiento deseados. Una vez que la función, el rendimiento, las restricciones y las interfaces están delimitados, el analista de sistemas procede a realizar la tarea denominada asignación. Durante la asignación, las funciones son asignadas a uno o más elementos genéricos del sistema (esto es, software, hardware, gente, etc.).

3.2. Hardware e ingeniería del hardware El ingeniero de sistemas de computadora selecciona alguna combinación de componentes de hardware que constituyen un elemento del sistema basado en computadora. La selección del hardware, aunque no es una tarea sencilla, se ve facilitada por una serie de características como: Los componentes están empaquetados como bloques individuales Las interfaces entre componentes están establecidas. Están disponibles numerosas alternativas “preparadas” El rendimiento, costo y disponibilidad son relativamente fáciles de determinar. La ingeniería del hardware para computadoras digitales surgió de los precedentes establecidos en décadas de diseño electrónico. El proceso de la ingeniería del hardware puede verse en tres fases: planificación y especificación; implementación del diseño y del prototipo; fabricación, distribución y mantenimiento. Una vez que se ha definido la ingeniería del sistema (análisis y definición del sistema), se asignan funciones al hardware. La primera fase de la ingeniería del hardware comprende la planificación del desarrollo y el análisis de los requisitos del hardware. La planificación del desarrollo se orienta a establecer el alcance del esfuerzo en hardware.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.3. Software e Ingeniería del Software La ingeniería del software es una disciplina para el desarrollo de software de alta calidad para sistemas basados en computadora. Durante la ingeniería del sistema se asigna la función y el rendimiento al software. En algunos casos, la función es simplemente la implementación de un procedimiento secuencial de manipulación de datos. El rendimiento no queda explícitamente definido. En otros casos, la función es la coordinación y control internos de otros programas concurrentes y el rendimiento está definido de forma explícita en términos de tiempo de espera y de respuesta. Para conseguir la función y el rendimiento, el ingeniero de software debe construir o adquirir una serie de componentes de software. A diferencia del hardware, los componentes de software están muy poco estandarizados . En la mayoría de los casos, el ingeniero de software crea componentes a la medida para satisfacer los requisitos asignados al elemento de software que se va a desarrollar. El elemento de software de un sistema basado en computadora está compuesto por programas, datos y documentación que constituyen el software de la aplicación y el software del sistema. El software de la aplicación implementa los procedimientos requeridos para realizar las funciones de procesamiento de la información. El software del sistema implementa funciones de control que permiten al software de la aplicación comunicarse con otros elementos de software. La ingeniería de software es la disciplina dentro de la informática encargada de la creación de software de calidad. El software es el conjunto de instrucciones que permite al hardware de la computadora desempeñar trabajo útil. En las últimas décadas del siglo XX, las reducciones de costo en hardware llevaron a que el software fuera un componente de gran participación en muchos de los dispositivos usados por las sociedades industrializadas. Así mismo, se considera parte del software a la documentación generada durante el desarrollo del proyecto. En la ingeniería de software podemos identificar claramente cuatro paradigmas, entre los cuales destacamos. El ciclo de vida clásico, la creación de prototipos, el modelo en espiral y las técnicas de cuarta generación. Cada uno es distinto de los otros, pero todos contemplan tres grandes fases como son: Fase de definición. La fase de definición de la ingeniería del software, representada en la (Figura 1), comienza con la etapa de planificación del software. Durante esta etapa se realizan las siguientes tareas: Se desarrolla una descripción bien delimitada del ámbito del esfuerzo de software.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Se lleva a cabo un análisis del riesgo. Se definen los recursos necesarios para desarrollar el software. Se establecen las estimaciones de tiempos y costos. El propósito de la etapa de planificación del software es proporcionar una indicación preliminar de la viabilidad del proyecto de acuerdo con el costo y con la agenda que se hayan establecido. La gestión del proyecto realiza y revisa un plan del proyecto de software. El siguiente paso en la fase de definición es el análisis y la definición de los requisitos del software. En este paso se define en detalle el elemento del sistema asignado al software. Los requisitos se analizan y se definen de una de dos maneras. Se puede hacer un análisis formal del ámbito de información para establecer modelos para convertirlos en una especificación del software. Alternativamente, se puede construir un prototipo del software, que será evaluado por el cliente para intentar consolidar los requisitos. Los requisitos de rendimiento y las limitaciones de recursos se traducen en características para el diseño del software. El análisis y definición de los requisitos del software es un esfuerzo conjunto llevado a cabo por el desarrollador del software y el cliente. La especificación de requisitos del software es el documento distribuible que se produce como resultado de esta etapa. Esta fase de definición culmina con una revisión técnica de la especificación de requisitos del software realizada por el grupo interdisciplinario formado por el desarrollador, el cliente y auditores de sistemas. Una vez que se han definido los requisitos, se vuelve a revisar el plan del software con el fin de comprobar que sigue siendo correcto.la información no cubierta durante el análisis de requisitos puede influir en las estimaciones hechas durante la planificación.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Fase de desarrollo. La fase de desarrollo (Figura 2), traduce un conjunto de requisitos en el elemento operativo del sistema que llamamos software. El primer paso de la fase de desarrollo se centra en el diseño. El proceso de diseño del software comienza con una descripción del diseño arquitectónico y de datos. Es decir, se desarrolla una estructura modular, se definen las interfaces y se establece la estructura de datos. Se revisa el paso preliminar del diseño para garantizar que esté completo y el seguimiento de los requisitos del software. A continuación, se consideran los aspectos procedimentales de cada componente modular del diseño del software. Cada descripción procedimental detallada se añade a la especificación del diseño, una vez revisada. Una vez terminado el diseño, se lleva a cabo la codificación o código fuente, la generación de un programa que use un lenguaje de programación apropiado o una herramienta CASE.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Fase de verificación, lanzamiento y mantenimiento. Durante la última fase del proceso de ingeniería del software (figura 3), el ingeniero de software prueba el software para encontrar el mayor número posible de errores antes de que sea puesto en producción o distribuido a terceros, lo prepara para su lanzamiento y lo mantiene a lo largo de toda su vida útil. Después de haber generado el código fuente, se lleva a cabo una serie de actividades de verificación y validación. Las pruebas de unidad intentan verificar el rendimiento funcional de cada componente modular individual del software. La prueba de integración constituye un medio de construcción de la arquitectura del software y de prueba de su funcionamiento y de su interfaces. La prueba de validación comprueba que se han conseguido todos los requisitos. Tras cada uno de estos pasos de prueba, puede que haya de realizarse una depuración, diagnostico y corrección de defectos. Para los pasos de prueba, se puede desarrollar un plan y procedimiento de prueba. Es recomendable realizar una revisión de la documentación, de los casos de prueba y de los resultados de las pruebas. Una vez terminada la prueba del software, éste está casi preparado para ser entregado a los usuarios finales. Sin embargo, es fundamental entes de la entrega llevar a cabo una serie de actividades de garantía de calidad para asegurar que se han generado y catalogado los registros y los documentos internos adecuados, que se han desarrollado una documentación de alta calidad para el usuario y que se han establecido los mecanismos apropiados de control de configuraciones. Entonces, el software ya puede ser distribuido a los usuarios finales.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

No se deben confundir los términos “ingeniería de sistema de computadora” e “ingeniería de computadoras”. La primera se centra primordialmente en el diseño y la implementación del hardware de computadora y su software asociado, mientras que la segunda se aplica a todos los productos y sistemas que contienen computadoras. El uso del enfoque orientado a objetos (Unidad 3 y 4) nos lleva a disponer de bloques de construcción de software reutilizable. Ingeniería del Software. Roger S. Pressman, pg. 150

3.4. Factores humanos e ingeniería humana Un sistema basado en computadora casi siempre tiene un elemento humano. Una persona que interactúa directamente con el hardware y con el software, manteniendo un diálogo que dirija el funcionamiento del sistema; en cualquier caso, la responsabilidad del desarrollo y del mantenimiento del sistema es la gente. La percepción del elemento humano de los sistemas basados en computadora forzaba al usuario a comunicarse de una forma que fuera fácil de implementar en hardware y software. Hoy, la expresión “amigable con el usuario” tiene un nuevo significado. La ingeniería humana para los sistemas basados en computadora es considerada como un paso importante del desarrollo de sistemas. La ingeniería humana es una actividad multidisciplinaria que aplica un conocimiento derivado de la psicología para especificar y diseñar IHM (Interacción Hombre-Máquina) de alta calidad. El proceso de la ingeniería humana comprende los siguientes pasos:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Análisis de actividad. Cada actividad asignada a un elemento humano se evalúa en el contexto de la interacción requerida con otros elementos. Análisis y diseño semántico. Se define el significado preciso de cada acción requerida del usuario y de cada acción producida por la maquina. Diseño léxico y semántico. Se identifica y representa la forma específica de las acciones y las ordenes. Después, se diseña la implementación en software y en hardware de cada acción y orden. Diseño del entorno de usuario. El hardware, software y otros elementos del sistema se combinan para formar un entorno de usuario. El entorno puede incluir facilidades físicas (brillo, utilización del espacio, etc.). Creación de prototipos. Es difícil, si no imposible, especificar formalmente una IHM sin usar un prototipo. La creación de prototipos permite evaluar la IHM (Interacción Hombre-Máquina) desde una perspectiva humana, con una participación activa en lugar de una evaluación pasiva.

3.5. Bases de datos e ingeniería de bases de datos No todos los sistemas basados en computadora hacen uso de una base de datos, pero para aquellos que si lo hacen, ese almacén de información a menudo es crucial para el funcionamiento general del sistema. La ingeniería de bases de datos (término relativamente nuevo que comprende análisis, diseño e implementación de bases de datos) es una disciplina técnica que se aplica una vez que se ha definido el alcance de la información. Por ello, el papel del ingeniero de sistemas es el de definir la información que va a contener la base de datos, los tipos de peticiones que se podrán procesar, la manera en que se accederá a los datos y la capacidad de la base de datos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4. Especificación del Sistema 4.1. Análisis Del Sistema El análisis del sistema es una actividad que abarca la mayoría de las tareas contenidas en ingeniería de sistemas basados en computadoras. En algunas ocasiones se entra en confusión porque el término se usa a menudo en un contexto que alude solo a las actividades de análisis de requerimientos del software (Vea la unidad 2). El propósito de esta unidad, el análisis del sistema se centra en todos los elementos del sistema, no solo en el software. Para el desarrollo de un análisis de sistema es necesario tener presente los siguientes objetivos: Identificar las necesidades del cliente. Evaluar la viabilidad del sistema Llevar a cabo un análisis técnico y económico Asignar funciones al software, al hardware, a la gente, a la base de datos y a otros elementos del sistema. Establecer claramente las restricciones de costo y tiempo. Realizar un estudio de Costo/Beneficio. Dar una definición acertada del sistema que se convierta en la base para todo el trabajo posterior de ingeniería. Para alcanzar con éxito estos objetivos, se requiere conocimiento y experiencia en software y hardware, igual en ingeniería humana y en bases de datos.

4.2. Identificación de las necesidades El primer paso del proceso de análisis del sistema implica la identificación de las necesidades. El analista se entrevista con el cliente o su representante. El cliente puede ser un representante de una compañía externa. La identificación de las necesidades es el punto de partida en la evolución de un sistema basado en computadora. Para empezar, el analista da asistencia al cliente definiendo los objetivos del sistema (producto): La información que se va a obtener La información que se va a suministrar Las funciones El rendimiento requerido

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

El analista se asegura de distinguir entre lo que “necesita” el cliente (elementos críticos para la realización) y lo que el cliente “quiere” (elementos deseados pero no necesarios). Una vez que se han identificado todos los objetivos, el analista pasa a una evaluación de la información suplementaria, formulando algunas preguntas como: ¿Existe la tecnología necesaria para construir el sistema? ¿Qué recursos de fabricación y de desarrollo especiales se requerirán? ¿Qué límites se han impuesto a los costos y a la agenda? Si el nuevo sistema es un producto que va ha ser desarrollado para venderlo a muchos clientes también se hacen las siguientes preguntas: ¿Cuál es el mercado potencial para el producto? ¿Cómo se compara este producto con los de la competencia? ¿Qué lugar ocupa este producto dentro de la línea general de la compañía? La información recogida durante la etapa de identificación de las necesidades se especifica en un documento de conceptos del sistema. Algunas veces, es el cliente quien prepara un documento de conceptos inicial antes de reunirse con el analista. Indistintamente, los resultados de la comunicación analista–cliente producen modificaciones en el documento.

4.3. Estudio de viabilidad Todos los proyectos son realizables - ¡con recursos ilimitados y un tiempo infinito! Desafortunadamente, el desarrollo de un sistema basado en computadora se caracteriza por la escasez de recursos y la dificultad de cumplir los plazos de entrega. De acuerdo a esto es necesario y prudente evaluar la viabilidad de un proyecto lo antes posible.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Unidad 2

Ingeniería de Requerimientos Es fundamental entender los requerimientos, antes de que el diseño y la desarrollo de un proyecto de software puedan iniciar. Esto es posible lograrlo llevando a cabo una serie de actividades de ingeniería de requerimientos, las cuales se realizan durante las actividades de comunicación con el cliente. El grupo interdisciplinario o equipo de software desarrollan diferentes funciones dentro de la ingeniería de requerimientos como son: inicio, obtención, elaboración, análisis del problema, evaluación y negociación, especificación, validación, evolución y gestión. Cuando se inicia el proyecto el analista desarrollador y el cliente, así como otros interesados establecen los requerimientos básicos del problema, definen las restricciones del proyecto y especifican las características y funciones más importantes que deben estar presentes en el software a construir para que este pueda alcanzar sus objetivos. Esta información es expandida y optimizada durante la obtención, una actividad para la recopilación de requerimientos que emplea reuniones que encabeza un moderador. Posteriormente se expande los requerimientos hacia un modelo de análisis; es decir, una colección de componentes del modelo basados en escenarios, en actividades y en clases, de comportamiento orientado al flujo. En la creación de estos componentes se puede utilizar una variedad del modelado. El modelo puede referirse a patrones de análisis, características del dominio del problema que son recurrentes a través de distintas aplicaciones. Una vez identificados los requerimientos y creado el modelo de análisis, el equipo de software, el cliente y otros interesados en el proyecto negocian la prioridad, disponibilidad y costo relativo de cada requerimientos. El objetivo principal de esta negociación es desarrollar un plan de proyecto realista. Por último, cada requerimiento y el modelo de análisis como un todo se validan confrontándolos con las necesidades del cliente para asegurar que se construirá el sistema correcto.

1. Ingeniería De Requerimientos La Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requerimientos de los clientes y usuarios, que pueden entrar en conflicto entre ellos. Puede ser conocida también como "Análisis de requerimientos", "Especificación de requerimientos", etc. Esta es una de las tareas más difíciles que enfrenta el ingeniero de software, ya que la comprensión de los requerimientos de un problema es difícil de entender debido a que el cliente, en la mayoría de las veces, no sabe lo que se requiere, los usuarios finales no entienden bien las características y funciones que les proporcionarán un beneficio. Aun si los clientes y usuarios finales son explícitos en sus necesidades, estos requisitos pueden cambiar durante el proyecto, de aquí su gran dificultad. El propósito de la ingeniería de requerimientos es hacer que los requisitos alcancen un estado óptimo antes de seguir adelante con el proyecto. Los buenos requerimientos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc. A partir de lo anterior, es indispensable definir algunos términos: ¿Qué es un requerimiento?, según la revista IEEE en su glosario presenta esta definición. Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Los requerimientos se pueden dividir en dos, así: Requerimientos funcionales Requerimientos no funcionales Los requerimientos funcionales, definen las funciones que el software será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales, tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

1.1. Características de los requerimientos: Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, debe presentar una serie de características tanto individual como en grupo. A continuación se presentan las más importantes.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

1.2. Dificultades para definir los requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros. Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

1.3. ¿Qué es la Ingeniería de requerimientos?, Es el proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema, además, ayuda a los ingenieros de sistemas a entender mejor el problema en cuya solución trabajaran. Incluye un conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuaran los usuarios finales con el software. La ingeniería de requerimientos tiene como meta entregar una especificación de requisitos de software correcta y completa.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

A continuación se presentan algunas definiciones para ingeniería de requerimientos. “Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema” Boehm 1979. “Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos” Leite 1987. “Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto” Rational Software ¿Quién lleva a cabo la IR ?, los ingenieros de software y otros interesados como gerentes, clientes y usuarios finales que participan en la ingeniería de requisitos ¿Cuál es la importancia?, es importante entender lo que el cliente quiere antes de empezar a diseñar y construir un sistema basado en computadora. El diseño y la construcción de un buen programa de computadora que resuelva el problema incorrecto no satisface las necesidades de nadie y por tanto el proyecto está destinado al fracaso.

1.4. Beneficios que se obtienen de la IR: Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE . Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1.5. Personas involucradas Requerimientos

Ingeniería

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan papeles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucre a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. Los roles del personal involucrado en el proyecto se pueden clasificar como sigue: Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la operatividad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario. Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema. Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan directamente con el cliente. Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente. Según la magnitud o complejidad del proyecto pueden estar involucradas otras personas como: Administradores de proyecto Documentadores Diseñadores de bases de datos, entre otros Puntos a tener en cuenta durante la Ingeniería de Requerimientos:

1.6. Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para descomponer el trabajo en tareas específicas. En ciertas situaciones la IR se enfoca en la descripción de las tareas y en el análisis de sistemas similares. Esta

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

información proporciona la base para especificar el sistema que será construido; aunque frecuentemente se añadan al sistema tareas que no encajan con el ambiente de trabajo planificado. El nuevo sistema cambiará el ambiente de trabajo, sin embargo, es muy difícil anticipar los efectos actuales sobre la organización. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en producción; también ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atención a la IR es la principal. Frecuentemente la especificación inicial es también la especificación final, lo que obstaculiza la comunicación y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados.

1.7. Punto de vista de los clientes Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario. Diferentes puntos de vistas también pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos. El tamaño y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos. Entre algunas de las dificultades cundo se trata del punto de vista de los clientes, tenemos: •

Barreras de comunicación

La ingeniería de requerimientos depende de una intensa comunicación entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicación. Para remediar esto, se deben abordar nuevas técnicas operacionales que ayuden a superar estas barreras y así ganar experiencia dentro del marco del sistema propuesto. •

Evolución e integración del sistema

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Pocos sistemas son construidos desde cero. En la práctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integración de componentes de varios proveedores. Para encontrar una solución a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseño; esto minimizará la cantidad de fallas directas en el código. •

Documentación de requerimientos

Los documentos de ingeniería de requerimientos son largos. La mayoría están compuestos de cientos o miles de páginas; cada página contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamaño, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificación de gran tamaño, pues difícilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta después de haberse construido el sistema.

1.8. Fases de implementación Fase de inicio: Tarea que define el alcance y la naturaleza del problema que debe resolverse Obtención, Tarea que ayuda al cliente a definir sus necesidades Elaboración, fase en la que se refinan y modifican los requerimientos básicos Negociación, es donde se define cuáles son las prioridades, cuáles aspectos son esenciales y en qué momento se requieren. Validación y revisión, esta etapa asegura que la concepción del problema que tiene el ingeniero de software coincide con la percepción del cliente. ¿Cuál es el Producto obtenido?, El objetivo del proceso de la IR es darle a todas las partes una explicación escrita del problema. Esto puede lograrse por medio de: escenarios de uso, lista de funciones y características, modelos de análisis o alguna especificación. Cómo puede estar seguro el ingeniero de software que lo hecho está correcto?, lo primero que debe hacer es revisar los productos de trabajo de la ingeniería de requisitos junto con el cliente y los usuarios finales para asegurarse que hayan entendido lo que en realidad pretendían decirles.

1.9. Técnicas para llevar a cabo un análisis de requisitos La ingeniería de requisitos es un proceso largo y arduo para el que se requiere de habilidades psicológicas y comunicativas.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

1.10. Entrevistas y cuestionarios Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requerimientos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallas. Las entrevistas pueden ser personales o grupales. El cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. Por lo general, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él. Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y generales que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales. Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema. Este tipo de preguntas son siempre apropiadas, además que ayudan a entender la perspectiva del afectado y no están influenciadas por el conocimiento de la solución. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Del Usuario • • • •

¿Quién es el cliente? ¿Quién es el usuario? ¿Tienen necesidades diferentes? ¿Cuáles son sus habilidades, capacidades, ambiente?

Del Proceso • • • •

¿Cuál es la razón por la que se quiere resolver este problema? ¿Cuál es el valor de una solución exitosa? ¿Cómo usted resuelve el problema actualmente? ¿Qué retrasos ocurren o pueden ocurrir?

Del Producto • • • •

¿Qué problemas podría causar este producto en el negocio? ¿En qué ambiente se usará el producto? ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento? ¿Qué obstáculos afectan la eficiencia del sistema?

El éxito de esta técnica combinada, depende de la habilidad del entrevistador y de su preparación para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cómo tratar con problemas potenciales. Asimismo, necesitan considerar no sólo la información que adquieren a través del cuestionario y la entrevista, sino también, su significado.

1.11. Talleres Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individualmente y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

1.12.

Prototipos

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Los prototipos pueden ser, por ejemplo, diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación. Explícitamente los prototipos permiten al desarrollador crear un modelo del software que debe ser construido. Al igual que todos los enfoques al proceso de desarrollo del software, el prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo. El prototipo es evaluado por el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Un proceso de iteración tiene lugar a medida que el prototipo es “puesto a punto” para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una mejor comprensión del problema por parte del desarrollador. Existen dos tipos de prototipos: Prototipo rápido: El prototipo rápido es un mecanismo para lograr la validación precompromiso. Se utiliza para validar requerimientos en una etapa previa al diseño específico. En este aspecto, el prototipo puede ser visto como una aceptación tácita de que los requerimientos no son totalmente conocidos o entendidos antes del diseño y la implementación. El prototipo rápido puede ser usado como un medio para explorar nuevos requerimientos y así ayudar a “controlar” su constante evolución. Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida está dividido en dos fases distintas: desarrollo y mantenimiento. La experiencia ha demostrado que esta distinción es arbitraria y va en contra de la realidad ya que la mayor parte del costo del software ocurre después de que el producto se ha entregado. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo de desarrollo. Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que se haya desarrollado el producto final. La adopción de este punto de vista elimina la distinción arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta las estrategias para la estimación de costos, enfoques de desarrollo y adquisición de productos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1.13. Objetivos medibles Los requerimientos formulados por los usuarios se toman como objetivos generales, a mediano o largo plazo, y en cambio se les debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto

1.14. Administración de requerimientos con casos de uso ¿Qué son los Casos de Uso? Los casos de uso son una técnica para especificar el comportamiento de un sistema: “Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.” Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresando pedido. También se puede decir que un caso de uso es una técnica para documentar posibles requerimientos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costos finales. Esta técnica se enfrenta a los siguientes peligros potenciales. A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final. Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez. Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Requisitos es sinónimo de requerimientos IEEE Std. 610. 12-1990 IR = Ingeniería de requerimientos Reparación de errores Se conoce como entorno todos aquellos que utilizan el sistema

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2. Puente Hacia Al Diseño Y La Construcción El diseño y la construcción de software son actividades creativas y un tanto divertidas. Es así, la construcción es tan irresistible que la mayoría de los desarrolladores de software quieren entrar en ella antes de comprender con claridad qué es lo que se necesita. La ingeniería de requisitos, como todas las demás actividades de la ingeniería del software, debe adaptarse a las necesidades del proceso, el proyecto, el producto y las personas que realizan el trabajo. Desde el punto de vista del proceso del software, la ingeniería de requisito (IR) es una acción de la ingeniería del software que comienza durante la actividad de comunicación y continua con el modelado. Se puede argumentar que la ingeniería de requisitos comienza al pie de los participantes del proyecto (es decir, gerentes, clientes, usuarios finales), es en donde se definen las necesidades del negocio, se describen los escenarios de los usuarios, se delinean las características y funciones y se identifican las restricciones del proyecto.

2.1. Actividades De Requerimientos

Ingeniería

La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación y administrar los requisitos conforme estos se transforman en un sistema operacional. Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en número como en nombres. Este proceso se lleva a cabo a través de las siguientes funciones: Punto de inicio Obtención Elaboración Análisis del Problema Evaluación y Negociación Especificación Validación Evolución Gestión Es de resaltar que algunas de estas funciones de la IR ocurren en paralelo y que cada una de ellas debe adaptarse a las necesidades del proyecto. Todas apuntan a definir lo que el

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

cliente quiere o ha solicitado y, además, sirven para establecer una base sólida respecto al diseño y la construcción de lo que obtendrá el cliente.

2.1.1. Punto de inicio La gran mayoría de los proyectos se inician cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. Los participantes de la unidad de negocios como (gerentes, gente de mercadotecnia, gerentes de una línea de producto etc.) definen un caso de negocios para la idea, tratan de identificar la amplitud y profundidad del mercado, hacen un análisis preliminar de factibilidad e identifican una descripción funcional del alcance del proyecto. Es probable que toda esta información esté sujeta a cambios, pero es suficiente para llevar a cabo conversaciones con la organización de ingeniería de software. Al iniciar el proyecto los ingenieros de software formulan una serie de preguntas libres de contexto, el objetivo es establecer una comprensión básica del problema, las personas que quieren una solución, naturaleza de la solución que se desea, y la efectividad de la comunicación preliminar entre el cliente y el desarrollador.

2.1.2. Obtención La obtención de requisitos es una tarea ardua y difícil, a simple vista parece algo sencillo pero no es así. Debido a que los clientes, usuarios y otros interesados no tienen claridad sobre lo que quieren. Christel y Kang identifican una serie de problemas que permiten ayudar a entender por qué es difícil la obtención de requisitos: Problemas de alcance, el límite del sistema está mal definido o los clientes, usuarios, especifican detalles técnicos innecesarios que pueden confundir, enredar en lugar de aclarar los objetivos generales del sistema. Problemas de comprensión, los clientes, usuarios, no están seguros por completo que es lo que se necesita, comprenden poco acerca de las capacidades y limitaciones de su ambiente de computo, no comprenden del todo el dominio del problema, tienen serias dificultades al comunicar sus necesidades al analista de sistemas, omiten información que consideran obvia, especifican requisitos ambiguos o inestables Problemas de cambio, Los problemas cambian conforme transcurre el tiempo

Para superar estos problemas los ingenieros de requisitos deben realizar de forma organizada la actividad de recopilación de información

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2.1.3. Elaboración La elaboración permite expandir y refinar la información conseguida con el cliente durante el inicio y la obtención. Esta actividad de la ingeniería de requisitos se centra en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración es una acción del modelado del análisis y se compone de una serie de tareas de modelado y refinamiento. La elaboración se lleva a cabo mediante la creación y el refinamiento de escenarios del usuario que describen la forma en que el usuario final y otros integrantes interactuarán con el sistema. Cada escenario del usuario debe ser analizado para obtener clases de análisis como: Entidades del dominio de negocios visibles para el usuario final Se definen los atributos de cada clase de análisis Se identifican los servicios que requiere cada clase. Se identifican las relaciones y la colaboración entre las clases y se produce una variedad de diagramas de UML complementarios. El resultado final de esta actividad es un modelo de análisis que define el dominio de la información, las funciones y el comportamiento del problema.

2.1.4. Análisis del problema El objetivo de esta actividad es entender las verdaderas necesidades del negocio. Antes de describir qué pasos se deben tener en cuenta en esta actividad, es necesario tener una definición clara del término “Problema”. “Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean”. Aquí se refleja la importancia que tiene una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Imagen extraída de la dirección: http://www.sxc.hu. Octubre del 2008. De uso libre para fines educativos

A través de la definición de problema, podemos ver entonces que la actividad de “Análisis del problema” tiene como objetivo primordial que se comprendan los problemas del negocio, se evalúen las necesidades iníciales de todos los involucrados en el proyecto y que se proponga una solución de alto nivel para resolverlo. Durante el análisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados en el proyecto, basados en los problemas reales del negocio. Los pasos a seguir son: •

Comprender el problema que se está resolviendo: Es importante determinar quién tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: “El cliente se queja mucho por la demora en la entrega de la mercancía”. Perspectiva del cliente = Deja de vender

Perspectiva de la distribuidora = Posibles pérdidas de clientes Posibles soluciones pueden ser, determinar por qué demoran los despachos, colocar nuevas personas en despacho (implica contratación de nuevas personas), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), poner a disposición nuevos vehículos de transporte (implica contratar nueva flota de transporte).

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las soluciones iníciales, deben ser definidas tomando en cuenta tanto la perspectiva técnica como la del negocio. o

Construir un vocabulario común: Debe diseñarse un glosario en dónde se definan todos los términos que tengan significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por ejemplo, las palabras despacho, recaudo, retención, nota crédito entre otras, son utilizadas para referirse a la acción de cartera (venta) como solicitud de un pedido previamente hecho y facturado.

La creación de un glosario es de un gran beneficio ya que reduce los términos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunión estén en la misma página, además de ser reutilizable en otros proyectos. o

Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante la ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la información necesaria para especificar un sistema adecuado.

Para saber quiénes son las personas, departamentos, organizaciones internas o externas que se verán afectadas por el sistema, se debe realizar algunas preguntas como: ¿Quién ¿Quién ¿Quién ¿Quién ¿Quién ¿Quién ¿Quién ¿Quién

usará el sistema que se va a construir? desarrollará el sistema? probará el sistema? documentará el sistema? dará soporte al sistema? dará mantenimiento al sistema? mercadeará, venderá, o distribuirá el sistema? se beneficiará por el retorno de inversión del sistema?

Como vemos, debe conocerse la opinión de todo aquél que de una u otra forma está involucrado con el sistema, ya sea directa o indirectamente. Definir los límites y restricciones del sistema: Este punto es importante pues debemos saber lo que se está construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir.

Evaluación y negociación de los requerimientos

En esta actividad juega un papel importante el ingeniero de requisitos, veamos por qué: es muy usual que los clientes y usuarios pidan más de lo que se puede lograr. También es

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

común que diferentes clientes y usuarios propongan requisitos que entran en conflicto entre sí, al argumentar que su propuesta es “fundamental para nuestras necesidades”. Debido a que los requerimientos provienen de diferentes fuentes, se hace necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término “adecuado” significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado. Los principales pasos de esta actividad son: o

Descubrir problemas potenciales: En este paso se asegura que todas las características descritas anteriormente estén presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc. Clasificación de los requerimientos: En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio.

Con base en la prioridad, cada requerimiento puede ser clasificado como mandatorio, deseable o innecesario. Un requerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario. Una vez hecha esta categorización de los requerimientos, se puede tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable. o

Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

En la actividad de evaluación y negociación, se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

• • • • • •

Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones.

2.1.5. Especificación de requerimientos de software La especificación de requerimientos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en cómo hará sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la ERS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores. Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema. Los clientes y usuarios utilizan la ERS para comparar si lo que se está proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de sistemas con base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolución del sistema. La ERS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la ERS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una ERS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una ERS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente. Las características de la ERS son verificadas en la actividad de Validación. La estandarización de la ERS es de suma importancia debido a que ayudará, entre otras cosas, a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados en el proyecto, además de asegurar que se cubren todos los tópicos importantes. La ERS es el producto de un trabajo final que genera la ingeniería de requerimientos, y además sirve como base para las actividades de la ingeniería del software subsecuentes.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Esta actividad también describe la función y el desempeño del software y las restricciones que regirán su desarrollo.

2.1.6. Validación de requerimientos La validación evalúa la calidad de los productos procedentes de la ingeniería de requerimientos. La validación de requisitos examina la especificación para asegurar que todos los requerimientos de software se han establecido de manera precisa; que se han detectado las inconsistencias, omisiones y errores y estos a su vez han sido corregidos, y que el trabajo realizado cumple con los estándares establecidos para el proceso, proyecto o producto. La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además Revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes. Es necesario recordar que la ERS debe estar libre de errores, por lo tanto, la validación Garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad. El objetivo primordial para la validación de requerimientos es la revisión técnica formal. El equipo de revisión que valida los requerimientos está compuesto por ingenieros de software, clientes, usuarios, auditores de sistemas y otros interesados que examinan la especificación y buscan errores en el contenido o la interpretación, áreas que tal vez requieran una clarificación, información faltante, inconsistencias. (Esto cobra vigencia o es importante cuando se trata de sistemas grandes), aquí aparecen conflictos entre los requisitos, o requisitos Inalcanzables (irreales). Estos son algunos de los puntos de verificación para la validación de requisitos: ¿Los requisitos están establecidos de manera clara? ¿Estos pueden mal interpretarse? (entendible) ¿La fuente del requisito (por ejemplo, una persona, un reglamento) está identificada? ¿El enunciado final del requisito ha sido examinado por la fuente original? (verificable) ¿Se ha creado algún índice para la especificación? (clara) ¿El requisito está restringido en términos cuantitativos? (verificable) ¿La especificación está estructurada de una forma que conduzca a su comprensión, referencia y traducción fácil en productos de trabajo más técnicos? (clara) ¿Están incluidas todas las funciones requeridas por el cliente? (completa)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

¿Existen conflictos en los requerimientos? (consistencia) ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) ¿Está cada requerimiento claramente representado? (entendible) ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible) ¿Está la ERS escrita en un lenguaje apropiado? (clara) ¿Existe facilidad para hacer cambios en los requerimientos? (modificable) ¿Está claramente definido el origen de cada requisito? (rastreable) ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable) La validación de requerimientos es de una gran importancia, pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.

2.1.7. Evolución de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios, y cómo los objetivos de la organización pueden cambiar, por tanto, es necesario planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo, que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las más frecuentes son: Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Porque cambió el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambiaron las reglas de negocio. Porque cambió el mercado en el cual se desenvuelve el negocio. Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del código fuente, ya que evita tener requerimientos con parches en un proyecto. Entre algunos de los beneficios que proporciona el control de versiones

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Son: Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de “releases ”. Prevenir la modificación simultánea a los requisitos. En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

2.1.8. Gestión de requerimientos La gestión de requerimientos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requerimientos o requisitos y los cambios a éstos en cualquier momento mientras se desarrolla el proyecto. La gestión de requerimientos comienza con la identificación de los requisitos. Una vez identificados los requerimientos se desarrollan las tablas de rastreabilidad. Estas son algunas de las tablas de rastreabilidad: Características, muestra la manera en que los requerimientos se relacionan con las características del sistema observables para el cliente Fuente, Identifica la fuente de cada requerimientos Dependencia, Indica la forma en que los requerimientos están relacionados entre si Interfaz, Muestra la forma en que los requisitos se relacionan con las interfaces internas y externas del sistema Subsistema, Establece categoría entre los requerimientos de acuerdo con el subsistema Estas tablas de rastreabilidad en la mayoría de las veces, se mantienen como parte de la base de datos de los requerimientos de manera que se puedan buscar con rapidez para entender como el cambio en un requerimiento afectara distintos aspectos del software que se desarrollara.

• • • • •

Especificación de requisitos de software Requerimiento con parche es aquel que ha tenido cambios excesivos en su contenido Entrenamiento y creación Interconexión de redes enrutada con RIP para IP utiliza el protocolo de enrutamiento RIP para IP con el fin de comunicar dinámicamente información de enrutamiento entre enrutadores Christel, M. G. y K. C. Kang, “Issues in Requirements Elicitation”, en Software Engineering Institute, Sep 1992

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Inicio Del Proceso De La Ingeniería De Requerimientos Cuando se inicia un proyecto informático, el escenario ideal es que los clientes y los ingenieros de software trabajen juntos en el mismo equipo. Sin embargo, en la realidad a menudo es bastante diferente. Puede suceder que los clientes tengan solo una idea vaga de lo que se quiere, o tal vez tengan ideas conflictivas acerca del sistema que se construirá, o por el contrario su conocimiento técnico sea limitado y tengan escaso tiempo para interactuar con el ingeniero de requerimientos. Nada de esto es sano para un proyecto pero es muy común que se dé, y el equipo interdisciplinario de trabajo con regularidad se ve obligado a trabajar dentro de las restricciones impuesta por esta situación.

3.1. Identificación de los beneficiarios del sistema Los interesados o posibles beneficiarios del sistema: gerentes de operaciones de negocios, gerentes de producto, personal de mercadeo, clientes internos y externos, usuarios finales, consultores, ingenieros de producto, ingenieros de software, ingenieros de soporte y mantenimiento y otros. Como se puede observar cada interesado tiene una visión diferente del sistema, obtiene beneficios diferentes cuando este se desarrolla de manera exitosa, y está abierto a diferentes riesgos si el esfuerzo de desarrollo llegara a fallar. En el inicio el ingeniero de requisitos puede crear una lista de personas que contribuirán durante la obtención de requisitos. Esta lista crecerá en la medida en que se establezcan contactos con los interesados, ya que a cada uno de ellos se le preguntará acerca del proyecto o con quien más se debe hablar.

3.2. Diferentes puntos de vista Los sistemas se exploran desde diversos puntos de vista, esto obedece a que existe diversidad de clientes con pensamientos distintos. Por ejemplo, consideremos tres grupos que hacen parte de la empresa DIDESOFT, estos grupos son: Mercadotecnia, Directores de negocios y Analistas de software.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Grupo 1: Mercadotecnia, en este grupo su interés está basado en funciones y características que estimulen al mercado potencial, que hagan que el nuevo sistema sea fácil de vender. Grupo 2: Directores de negocios, su interés apunta a un grupo de características que se pueda construir sin rebasar un presupuesto y que estén listas para llegar a nichos de mercados definidos. Grupo 3: Ingenieros de software, estos pueden estar interesados en funciones que den el soporte de la infraestructura y características más accesibles al mercado. Como se puede ver cada uno de estos grupos y otros proporcionarán información al proceso de la ingeniería de requisitos. Conforme se recopila información desde múltiples puntos de vista, los requisitos que surjan pueden ser inconsistentes o entrar en conflicto con algún otro. Bajo esta premisa podemos concluir que el trabajo del ingeniero de requisitos es categorizar toda la información de los interesados, (incluidos los requisitos con conflictos o inconsistentes), de forma que permita a quienes tomen la decisión elegir un conjunto de requisitos para el sistema que sea consistente.

3.3. Trabajo conjunto con los colaboradores Como es conocido el trabajo del analista de requisitos es identificar áreas en común, (esto es, los requisitos en que todos los interesados están de acuerdo) y áreas de conflicto o inconsistencia, (esto es, los requisitos solicitados por un interesado que entran en conflicto con las necesidades de otro), esto es todo un desafío que el analista debe resolver. Una forma de resolver los conflictos entre requisitos, es la utilización de un esquema de votación basado en puntos de prioridad. Todos los interesados reciben la misma cantidad de puntos de prioridad que pueden “gastarse” en cualquier número de requisitos. Se presenta una lista de requisitos y los interesados indican la importancia relativa de cada una, desde su punto de vista, al asignarle uno o más puntos de prioridad. Los puntos asignados no se pueden reutilizar. Una vez que los puntos de prioridad del interesado se han agotado, esta persona no puede realizar ninguna otra opción sobre los requisitos. Los puntos totales que asignen en cada requisito, todos los interesados, indican la importancia general de cada requisito. La colaboración no significa, necesariamente, que los requisitos se definan por consenso. En la mayoría de los casos, los interesados colaboran al proporcionar su visión de los requisitos, pero un gerente líder del proyecto o un técnico importante puede tomar la decisión final acerca de cuáles requisitos se aceptan.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.4. Formulación de las primeras preguntas El primer grupo de preguntas libres de contexto se enfoca en el cliente y otros interesados, y lo podemos enmarcar en metas generales y en los beneficios. Por ejemplo el ingeniero de requisitos podría preguntar: ¿Quién está detrás de este proyecto? ¿Quién usará la solución? ¿Qué beneficio económico espera de una solución exitosa? ¿Existe otra fuente para la solución requerida? Estas preguntas ayudan a identificar a todos los participantes que tendrían interés en el proyecto que será construido. Además, estas preguntas identifican el beneficio medible de una implementación exitosa y sus alternativas posibles para personalizar el desarrollo del software. Otra serie de preguntas permite que el equipo de analistas comprenda mejor el problema y permite que el cliente exprese sus percepciones acerca de una solución: ¿Cómo podría caracterizarse un buen resultado generado por una solución exitosa? ¿Cuáles problemas debería atacar esta solución? ¿El desempeño o las restricciones afectaran la forma en que se busque la solución? Una serie final de preguntas se enfoca en la efectividad de la actividad de comunicación: ¿Es usted la persona adecuada para contestar esta pregunta? ¿Sus respuestas son oficiales? ¿Mis preguntas son relevantes para su problema? ¿Estoy haciendo demasiadas preguntas? ¿Alguien más puede proporcionar información adicional? Estas preguntas y otras ayudaran a romper el hielo permitiendo iniciar una conversación esencial para la obtención exitosa de información. El formato de preguntas y respuestas no es un enfoque que haya sido exitoso de manera contundente. De hecho esta sesión de preguntas y respuestas debe usarse sólo para el primer encuentro, y después se debe remplazar por un formato de obtención de requisitos que contiene elementos de resolución de problemas, negociación y especificación.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4. Obtención De Requerimientos El formato de preguntas y respuestas descrito anteriormente es útil en la etapa inicial, ya que como se afirmo anteriormente, no es un enfoque que haya sido exitoso de manera decisiva para una obtención de requisitos más detallada del proyecto.

4.1. Recopilación de requerimientos La recopilación de requisitos debe ser un esfuerzo conjunto del equipo de trabajo conformado por participantes (Usuarios) y desarrolladores (Analistas), esto conlleva a que el grupo identifique el problema, proponga elementos de solución, negocie diferentes enfoques y especifique un conjunto preliminar de requisitos para la solución.

Imagen extraída de la dirección: http://www.sxc.hu. Octubre del 2008. De uso libre para fines educativos

Se han propuesto diferentes enfoques para la recopilación conjunta de requisitos. Donde cada uno de ellos utiliza un escenario diferente, pero todos aplican alguna variación de las siguientes directrices básicas: Reuniones, estas son dirigidas por alguno de los asistentes, ya sea un ingeniero de software o un usuario Se establecen reglas para la preparación y la participación Un moderador (puede ser un cliente, un desarrollador o un agente externo) controla la reunión

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Se sugiere una agenda que sea tan formal como para cubrir todos los puntos importantes, pero tan informal como para estimular el flujo de ideas. Se utiliza un mecanismo de definición, (puede ser hojas de trabajo, gráficos, un tablero electrónico, un mensajero electrónico o un foro virtual). La meta es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto de requisitos de solución que conduzca al cumplimiento de la meta. Durante la fase de inicio las preguntas y respuestas básicas establecen el alcance del problema y la percepción global de una solución. Fuera de estas reuniones iníciales, los participantes escriben una solicitud de proyecto de una o dos páginas. Se fija un lugar, una hora y una fecha para la reunión y se nombra un moderador. Los miembros del equipo de software y otras aéreas interesadas son invitados a asistir. La solicitud del proyecto se distribuye a todos los asistentes antes de la fecha de reunión. Se pide a cada asistente hacer una lista de objetos que son parte del ambiente que rodea al sistema, otros objetos que este producirá, y objetos que utiliza para realizar sus funciones.

4.2. Despliegue de la función de calidad (DFC) El despliegue de la función de calidad es una técnica que traduce las necesidades del cliente en requisitos técnicos para el software. El DFC se concentra en aumentar la satisfacción del cliente desde el proceso de la ingeniería del software. Para lograr lo anterior, el DFC resalta una comprensión de lo que es valioso para el cliente y después despliega estos valores durante el proceso de ingeniería. El DFC identifica tres tipos de requerimientos: Requerimientos normales. Reflejan los objetivos y metas establecidos para un producto o sistema durante las reuniones con el cliente. Si estos requisitos están presentes entonces el cliente estará satisfecho. Requerimientos esperados. Están implícitos en el producto o sistema y pueden parecer tan obvios, aunque son fundamentales, que el cliente no los establece de manera explícita. Su ausencia ocasionaría una insatisfacción significativa. Algunos ejemplos de requisitos esperados son la facilidad de la interacción humano/máquina, corrección y confiabilidad operacional general. Requerimientos estimulantes. Reflejan las características que van más allá de las expectativas del cliente y que prueban ser muy satisfactorias cuando están presentes. Por ejemplo, el producto entregado contiene varias capacidades de configuración de página que son bastante satisfactorias e inesperadas, (valor agregado).

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4.3. Escenarios del usuario De acuerdo a como se recopilan los requerimientos se comienza a materializar una visión general de las funciones y características del proyecto informático. Es importante resaltar que al equipo de software se le hace difícil continuar con las actividades de ingeniería de software, si no entiende la manera en que las distintas clases de usuarios finales aplican estas funciones y restricciones. Para lograrlo, los analistas y usuarios pueden crear un conjunto de escenarios que identifica una cadena de uso para el proyecto informático que se va a construir. Los escenarios, llamados con frecuencia casos de uso, proporcionan una descripción de cómo se usará el sistema.

4.3.1. Beneficios del trabajo de la recopilación de requerimientos Los beneficios del trabajo obtenido como consecuencia de la recopilación de requisitos varían de acuerdo con el alcance o tamaño del sistema que se vaya a construir. La gran mayoría de los proyectos informáticos incluyen los siguientes beneficios del trabajo: Un enunciado en donde se describe las necesidades del usuario y factibilidad. Un enunciado breve del alcance del proyecto informático. Una descripción del ambiente técnico del sistema. Una lista de clientes, usuarios y otros interesados que participaron en la obtención de requerimientos. Una lista de requerimientos organizados por función y las restricciones de dominio aplicadas a cada uno. Un conjunto de escenarios de uso que proporcionen un pensamiento de la utilización del sistema en diferentes condiciones de operación. Desarrollo de prototipos para definir de mejor forma los requerimientos. Cada uno de estos beneficios de trabajo deben ser revisados por el personal involucrado en el proyecto y que ha sido partícipe de la obtención de requerimientos.

Despliegue de la función de calidad

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5. Casos De Uso Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que el sistema debe hacer. Los Casos de Uso son lo que hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario. Si se han enfrentado alguna vez a UML normalmente habrán visto algún diagrama de clases y esperarán que los Casos de Uso sean también una forma visual de representar la información. Sin embargo están muy equivocados, si bien los casos de usos se pueden agrupar en diagramas, los diagramas no son lo importante. Si lo primordial de los casos de uso no son los diagramas, entonces ¿qué es lo importante? Lo realmente útil de los casos de uso es el documento que describe el caso de uso, en esta unidad se explica la forma en que interactúa el sistema y el usuario. Pero lo más claro es que se presente uno. Este podría ser el caso de uso de escribir un mensaje en un foro. Nombre: Crear mensaje foro Autor: Juan Ramírez Fecha: 24/07/2007 Descripción: Permite crear un mensaje en el foro de discusión. Actores: Usuario de Internet logueado. Precondiciones: El usuario debe haberse logueado en el sistema. Flujo Normal:

1. El actor pulsa sobre el botón para crear un nuevo mensaje.

2. El sistema muestra una caja de texto para

introducir el título del mensaje y una zona de mayor tamaño para introducir el cuerpo del mensaje. 3. El actor introduce el título del mensaje y el cuerpo del mismo. 4. El sistema comprueba la validez de los datos y los almacena.

Flujo Alternativo:

1. El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

actor de ello permitiéndole que los corrija Pos condiciones: El mensaje ha sido almacenado en el sistema. Saltándose los campos evidentes como nombre, autor, fecha y descripción; los actores son aquellos que interactúan con el sistema. Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo. Luego tenemos el flujo de eventos, que corresponde a la ejecución normal y exitosa del caso de uso. Los flujos alternativos son los que nos permiten indicar qué es lo que hace el sistema en los casos menos frecuentes e inesperados. Por último, las post condiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha ejecutado correctamente. Otra forma de representar un diagrama de casos de uso es la siguiente:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5.1. Realización Del Modelo De Análisis El objetivo del modelo de análisis es describir los dominios requeridos de información, funcionamiento y comportamiento para un proyecto informático. En la medida en que los ingenieros de software aprenden más acerca del sistema ha construir y los interesados entienden mejor lo que necesitan, el modelo cambia dinámicamente. Es por esta razón que el modelo de análisis es una representación de los requerimientos en un momento determinado, por lo que se espera que este cambie. Conforme el modelo de análisis evoluciona, ciertos elementos se volverán relativamente estables, por lo que proporcionará una base solida para las tareas de diseño que siguen.

5.1.1. Componentes del modelo de análisis La recopilación de requisitos para un proyecto de software presenta diferentes vías. Algunas personas involucradas con el software dicen que lo mejor es seleccionar un modo de representación, (por ejemplo, el caso de uso) y aplicarlo sin tomar en cuenta todos los modos restantes. Otros profesionales creen que resulta valioso utilizar varios modos de representación para mostrar el modelo de análisis. Las distintas formas de representación obligan al equipo de software a considerar los requisitos desde diferentes puntos de vista, un enfoque que ofrece mayores probabilidades de descubrir omisiones, inconsistencias y ambigüedades. Existe un conjunto de componentes genéricos común a la mayoría de los modelos de análisis como: Componentes basados en escenarios. El usuario describe el sistema desde su punto de vista, por medio de un enfoque basado en escenarios. Por ejemplo, los casos de usos básicos y sus correspondientes diagramas de caso de uso (figura 2). Estos a su vez evolucionan para convertirse en casos de uso más refinados basados en plantillas. Los componentes del modelo de análisis basados en escenarios por lo regular son los primeros que se desarrollan durante la elaboración del modelo. Por consiguiente, sirven como una entrada para la creación de otros componentes de modelado. Diagramas de actividad en UML para la obtención de documentos. UML (Lenguaje de Modelamiento Unificado) es un lenguaje usado para especificar, visualizar y documentar los componentes de un sistema en desarrollo orientado a objetos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Figura tomada del texto, Ingeniería del Software de Roger S. Pressman

Componentes basados en clases. Los componentes basados en clases consisten en que cada escenario de uso implica un conjunto de objetos que son manipulados por el actor que interactúa con el sistema. Estos objetos se clasifican en clases: colección de clases con atributos similares y comportamientos en común. Por ejemplo, diagrama de clase para mostrar una clase de Empleado

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Lo anterior se examina con mayor detalle en la unidad 3 Componentes de comportamiento. El comportamiento de un proyecto de software puede tener un amplio efecto sobre el diseño que se elija, así como en el enfoque de implementación que se aplique. Por tanto, el modelo de análisis debe proporcionar componente de modelado que muestren el comportamiento. El diagrama de estado es un método para representar el comportamiento de un sistema al mostrar sus estados y los eventos que ocasionan que dicho sistema cambie de estado. Estado: es cualquier forma de comportamiento observable. Además, el diagrama de estado indica las acciones que se toman como consecuencia de un evento particular.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Figura 4: Diagrama de estado, notación UML

Como se puede ver el rectángulo se divide en tres áreas:

1. Nombre del estado: lectura de comandos 2. Variables de estado que indican la manera en que el estado se manifiesta a sí mismo en el mundo exterior.

3. Actividades de estado que indican la forma en que se ingresa al estado (Entrada) y las acciones (do:) invocadas mientras se permanece en el mismo.

Componentes orientados al flujo. Cuando la información fluye a través de un sistema basado en computadora, ésta se transforma. El sistema acepta la entrada en una variedad de formas, aplica funciones para transformarla y produce una salida en formas diferentes. En la unidad 3 se presenta una exposición más detallada del modelado de flujo.

5.1.2. Patrones de análisis Geyer – Shultz y Hahsler sugieren dos beneficios que pueden asociarse con el uso de patrones de análisis:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Los patrones de análisis aceleran el desarrollo de modelos de análisis abstractos que capturan los requisitos principales del problema concreto al proporcionar modelos reutilizables del análisis, los cuales incluyen ejemplos, así como una descripción de las ventajas y limitaciones.

2. Los patrones de análisis facilitan la transformación del modelo de análisis en un modelo de diseño al sugerir patrones de diseño y soluciones confiables para problemas comunes.

Los patrones de análisis se integran al modelo respectivo mediante una referencia del nombre del patrón. Estos también se encuentran almacenados en un depósito para que puedan ser reutilizados por los ingenieros de software. La información acerca de un patrón de análisis se presenta en una plantilla estándar que tiene la siguiente forma: Nombre del patrón: un descriptor que captura la esencia del patrón. El descriptor se utiliza dentro del modelo de análisis cuando se hace alguna referencia al patrón. Intención: describe todo aquello que el patrón pretende lograr o representar o el problema que ataca dentro del contexto de un dominio de aplicación. Motivación: escenario que ilustra la forma en que el patrón se puede utilizar para atacar el problema. Fuerzas y contexto: descripción de los aspectos externos capaces de afectar la manera en que se utiliza el patrón, así como de los asuntos externos que serán resueltos cuando se aplique el patrón. Los aspectos externos pueden incluir cuestiones relacionadas con los negocios, restricciones técnicas externas, y asuntos relacionados con las personas. Solución: una descripción de la forma en que se aplica el patrón para resolver el problema, poniendo especial atención en los aspectos estructurales y de comportamiento. Consecuencias: se enfoca en lo que sucede cuando se aplica el patrón y en los cambios que se producen durante su aplicación. Diseño: examina la manera en que el patrón de análisis se puede lograr por medio de patrones de diseños conocidos. Usos conocidos: ejemplos de usos en sistemas reales en producción. Patrones relacionados: uno o más patrones de análisis que están relacionados con el patrón en cuestión, porque el patrón de análisis: 1) por lo general se utiliza con el patrón de estudio, 2) es similar en el sentido estructural a dicho patrón, 3) es una variación del mismo. En la unidad 3 se presentan ejemplos de patrones de análisis, así como otros análisis de este tópico.

Geyer-Schultz, A. y M, Hahsler, Software Engineering with Analysis Patterns, Noviembre 2001

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

6. Negociación De Requerimientos Por lo general el cliente y el analista desarrollador entran en un proceso de negociación, en el cual se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras características del producido frente al costo y el tiempo de puesta en el mercado. El objetivo de esta negociación es desarrollar un plan de proyecto que satisfaga las necesidades del cliente, al mismo tiempo que refleje las restricciones del mundo real, (como por ejemplo, tiempo, gente, presupuesto etc.), a la que está sometido el equipo interdisciplinario de software. Bohem, define un conjunto de actividades de negociación en el inicio de cada iteración del proceso del software. En lugar de la actividad sencilla de comunicación con el cliente, se definen otras actividades como: Identificación de los interesados clave en el proyecto. Determinación de las condiciones ganadoras de los interesados. Negociación de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar – ganar para todos los involucrados.

6.1. Validación De Requerimientos Cada componente creado del modelo de análisis, se debe examinar para conocer su solidez, sus omisiones y ambigüedades. A los requerimientos que representa el modelo, el cliente les da un orden de prioridad y serán agrupados en paquetes de requisitos que serán implementados como incrementos de software y entregados al cliente. La revisión del modelo de análisis se centra en las siguientes preguntas: ¿Cada requerimiento o requisito es alcanzable en el ambiente técnico que recibirá el sistema o producto? ¿Cada requerimiento se puede probar una vez que éste haya sido implementado? ¿Cada requerimiento está limitado y no es ambiguo? ¿Cada requerimiento es consistente con el objetivo general del sistema o producto? ¿Algunos requerimientos entran en conflicto con otros? ¿Todos los requerimientos han sido especificados con el grado apropiado de abstracción? Esto es, ¿algunos requisitos proporcionan un grado de detalle técnico que sea inapropiado en esta etapa? ¿El modelo de requerimiento refleja de manera apropiada la información, la función y el comportamiento del sistema que será construido? ¿Algunos requerimientos entran en conflicto con otros?

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

¿El modelo de requerimiento debe ser particionado para que exponga en forma progresiva información más detallada acerca del sistema? Tanto estas, como otras preguntas, deben realizarse y contestarse para asegurar que el modelo de requisitos es coherente con las necesidades del cliente y que proporciona una base fundamental para el diseño.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Unidad 3

Modelado de Análisis Lo fundamental del modelado del análisis es crear representaciones que muestren los requisitos del software para tres elementos básicos como la información, la función y el comportamiento. Esto se logra a través de la aplicación de dos enfoques distintos de modelo (pero sustancialmente complementarios): el análisis estructurado y el análisis orientado a objetos. Por un lado el análisis estructurado estima al software como un transformador de información. El análisis estructurado ayuda al ingeniero de sistemas a identificar los objetos de datos, sus relaciones y la forma en la cual estos objetos de datos se transforman mientras fluyen por las funciones de procesamiento del software…

Lo fundamental del modelado del análisis es crear representaciones que muestren los requisitos del software para tres elementos básicos como la información, la función y el comportamiento. Esto se logra a través de la aplicación de dos enfoques distintos de modelo (pero sustancialmente complementarios): el análisis estructurado y el análisis orientado a objetos. Por un lado el análisis estructurado estima al software como un transformador de información. El análisis estructurado ayuda al ingeniero de sistemas a identificar los objetos de datos, sus relaciones y la forma en la cual estos objetos de datos se transforman mientras fluyen por las funciones de procesamiento del software. El análisis orientado a objetos examina un dominio del problema definido como un conjunto de casos de uso en un esfuerzo por identificar clases que definen el problema. Cada clase contiene un conjunto de propiedades y métodos. Las clases se relacionan entre sí en diferentes variedades de forma y se moldean mediante la aplicación de diagramas de UML1. El modelo de análisis está compuesto por cuatro elementos básicos como: Modelos basados en escenarios Modelo de flujo Modelo basados en clases Modelos de comportamiento. Los modelos basados en escenarios, muestran los requerimientos del software desde el punto de vista del usuario. Es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de un lenguaje técnico prefiriendo, en su lugar, un lenguaje más cercano al usuario final. El caso de uso es una descripción narrativa o basada en una plantilla de una interacción entre un actor y el software, es el elemento primario del modelado. Los modelos de flujo, se enfocan procesamiento los transforman. utilizan el diagrama de flujo de entrada se transforma en una sistema.

en el flujo de objetos de datos de acuerdo a como las funciones de Los modelos de flujo que se derivan del enfoque estructurado, datos; esta notación de modelado muestra la manera como una salida, conforme los objetos de datos se mueven a través del

Modelo basado en clases, utiliza información derivada de elementos de modelado orientado al flujo y basado en escenarios para extraer clases candidatas, atributos y métodos de las narrativas basadas en texto. Se establecen los criterios para la definición de una clase en particular. Estos tres modelados del análisis proporcionan una visión estática del software. Mientras que los modelos de comportamiento muestran un desempeño dinámico. El modelo de comportamiento, utiliza la entrada de elementos basados en escenarios, orientado al flujo y basados en clases para representar los estados de las clases de análisis y del sistema como un todo. Esto se logra identificando los estados, definiendo los eventos que ocasionan que una clase tenga una transición de un estado a otro, e identificando las acciones que suceden cuando se realiza la transacción.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1. Modelado Del Análisis El modelado de análisis es una serie de modelos, es la primera representación técnica de un sistema. El modelado de análisis conduce a una especificación de requisitos y a una representación completa del diseño de software que será construido. El modelado de análisis utiliza una combinación de formatos en texto y diagramas para representar los requisitos de los datos, las funciones y el comportamiento de una manera fácil de entender y, además, conduce a una revisión para lograr la corrección, la integridad y la consistencia. Al observar los problemas y fallas reconocidas de la fase de análisis se hace necesario agregar algunos objetivos: Los productos del análisis deben tener una altísima facilidad de mantenimiento. Aplicable en particular al documento final (especificación de requisitos de software). Deben utilizarse gráficos cuando sea posible. Los problemas de gran tamaño deben tratarse con un método efectivo de partición. Se debe diferenciar entre consideraciones lógicas y físicas de implementación. Importancia del modelado de análisis: su importancia radica en validar los requisitos del software ya que es necesario examinarlos desde algunos puntos de vista diferentes. El modelado del análisis representa los requisitos en múltiples dimensiones, con lo que se incrementa la probabilidad de encontrar errores, inconsistencias y que se descubran omisiones. Tipos de diagramas en el modelado de análisis: El modelado basado en escenarios, representa el sistema desde el punto de vista del usuario. El modelado orientado al flujo, indica cómo se transforman los objetos de datos al realizarse las funciones del procesamiento. El modelado basado en clases, define objetos, atributos y relaciones. El modelado del comportamiento, presenta los estados del sistema y sus clases, así como el impacto de los eventos sobre sus estados. Producto obtenido, cada una de las representaciones de diagrama ofrece una visión de uno o más elementos del modelo. Como se puede estar seguro que lo hecho es correcto? la documentación del modelado de análisis debe revisarse cuidadosamente, garantizando con ello que el trabajo es optimo, y, además refleja las necesidades de todos los interesados. Con esto se establece una base desde la cual pueda conducirse al diseño.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

ANALISIS DE REQUISITOS

El análisis de requisitos genera la especificación de características operacionales del software, indica la interfaz del software con otros elementos del sistema, y establece las restricciones que debe tener el software. El análisis de requisitos permite al analista de sistemas se extienda sobre requerimientos básicos establecidos durante tareas anteriores a la ingeniería de requisitos y construya modelos que representen escenarios del usuario, actividades funcionales, clases de problemas y sus relaciones, el comportamiento de las clases y el sistema a medida que se transforma el flujo de datos. El análisis de requisitos proporciona al diseñador de software una representación de información, función y comportamiento que puede trasladar a diseños arquitectónico de interfaz y en el nivel de componentes. Por último, el modelado de análisis y la especificación de requisitos ofrecen al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software. Por medio del modelado de análisis el ingeniero de software se centra primero en el qué, no en el cómo. Ejemplo, “qué”: Qué objetos manipula el sistema?, Qué funciones debe desempeñar el sistema? Qué comportamiento muestra el sistema, Qué restricciones se aplican? y Qué interfaces se definen?.

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Posiblemente el desarrollador no esté seguro de qué enfoque especifico realizará la función y sí se desempeñará de manera apropiada. El analista debe modelar lo que se conoce y utilizar ese modelo como base para diseñar un incremento del software.

1.1. Filosofía y objetivos generales Son tres los objetivos primarios que debe cumplir el modelado de análisis: Describir lo que requiere el cliente. Establecer una base para la creación de un diseño de software. Definir un conjunto de requisitos que pueda validarse una vez construido el software. El modelo de análisis detalla la funcionalidad general del sistema, la cual se logra al aplicar el software, hardware, datos, humanos y otros elementos del sistema y del diseño de software que detallan la arquitectura de aplicación del software, la interfaz con el usuario y la estructura en el nivel de componente. Esta relación se ilustra en la figura 1

1.2. Reglas prácticas de análisis Reglas prácticas que deben seguirse para crear el modelo de análisis: El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. El grado de abstracción debe ser alto. “No se debe perder tiempo en detalles” que tratan de explicar cómo funcionará el sistema. Cada elemento del modelo de análisis debe agregarse a un acuerdo general de los requisitos de software y proporcionar una visión interna del dominio de información, función y comportamiento del sistema. Retrasar la consideración de la infraestructura y otros modelos no funcionales hasta el diseño. Por ejemplo, es posible que requiera una base de datos, pero las clases necesarias para implementarla, las funciones que se requieren para acceder a ella y el comportamiento que se exhibirá cuando se utilice debe considerarse sólo después de que se haya completado el análisis de dominio del problema. Se debe minimizar el acoplamiento de todo el sistema. es importante representar las relaciones entre clases y funciones. Se debe tener la seguridad de que el modelo de análisis proporciona valor a todos los interesados. Por ejemplo, los interesados relacionados con los negocios deben utilizar el modelo para validar los requisitos; los diseñadores, como base para el diseño; la gente de aseguramiento de la calidad, como ayuda para planear pruebas de aceptación. El modelo debe mantenerse tan simple como sea necesario. No se deben agregar diagramas adicionales cuando éstos no ofrezcan información nueva.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1.3. Análisis del dominio El análisis del dominio de software es la identificación, el análisis y la especificación de requisitos comunes de un dominio especifico de aplicación para, de manera típica, reutilizarlo en múltiples proyectos dentro de ese dominio de aplicación. El análisis de dominio orientado a objetos es la identificación, el análisis y la especificación de capacidades comunes reutilizables dentro de un dominio especifico de aplicación, en términos de objetos, clases, subensamblajes y marcos de trabajo. Los patrones de análisis a menudo ocurren de nuevo en muchas aplicaciones dentro de un dominio de negocio específico. Si estos patrones se definen y se clasifican por categoría que permitan al ingeniero de software reconocerlos y reutilizarlo, la creación del modelo de análisis se acelera. Lo importante de esto es que la probabilidad de aplicar patrones de diseño reutilizables y componentes ejecutables de software aumenta en forma sustancial. Esto ofrece tiempo al mercado y reduce los costos del desarrollo.

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Ahora surgen algunas preguntas: ¿Cómo se reconocen los patrones de análisis? ¿Quiénes los definen, los asignan a una categoría y los preparan para aplicarlos en proyectos posteriores? Las respuestas a estas preguntas residen en el análisis del dominio.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

1.4. Enfoques De Modelado Del Análisis El modelado de análisis presenta dos enfoques: Análisis estructurado, considera que los datos y el proceso que transforman los datos son entidades separadas. Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Los procesos que manipulan los objetos de los datos se modelan de tal manera que muestran cómo transforman los datos, mientras los objetos de datos fluyen por el sistema. Análisis orientado a objetos, este se centra en la definición de clases y en la manera en que estas colaboran entre ellas para efectuar los requisitos del cliente. El modelo de análisis aquí propuesto combina características de ambos enfoques, es común que los equipos de desarrollo elijan uno y excluyan todas las representaciones del otro. El cuestionamiento no es cuál es el mejor, sino que combinación de representaciones les proporcionará a los interesados el mejor modelo de requisitos de software y el puente más efectivo para el diseño.

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

2. Modelado De Datos Por lo general el modelado del análisis comienza con el modelo de datos. El analista de software define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos. Un modelo es una representación de la realidad. Aquí cabe el refrán que dice “una imagen vale más que mil palabras”, los modelos son en su mayoría representaciones graficas de la realidad. El modelado de datos es una técnica para la organización y la documentación de los datos de un sistema.

2.1. Objetos de datos Las personas tienen una idea clara de lo que es un objeto: conceptos adquiridos que nos permite sentir y razonar acerca de las cosas del mundo. Un objeto podría ser real o abstracto, por ejemplo una organización, una factura, una figura etc. Entonces, un objeto de datos es una representación de cualquier información compuesta que el software debe entender. Cuando se habla de información compuesta esta se refiere a algo que tiene muchas propiedades o atributos diferentes. Por ejemplo “nombre” (un valor individual) no sería un objeto de dato valido, pero las personas (la incorporación de apellidos, nombres, teléfono y dirección) podrían definirse como un objeto. Un objeto de datos puede ser una entidad externa (por ejemplo, cualquier cosa que produzca o consuma información), una cosa por ejemplo, un reporte. Un objeto de datos encapsula solo datos: no existe alguna referencia dentro de un objeto de datos a las operaciones que actúen sobre los datos. Por tanto, el objeto de datos puede representarse como una tabla, tal como se muestra en la figura 3.4. Los encabezados de la tabla reflejan los atributos del objeto. En este caso, un empleado se define en términos de (Nº de Id, Nombre, teléfono, dirección, sexo, cargo y salario) el contenido de la tabla representa ejemplos específicos del objeto de datos. Por ejemplo, el empleado Juan Medina es una muestra del objeto de datos empleado.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

2.2. Atributos Los atributos defines las propiedades de un objeto de datos y toman una de las tres características diferentes: Nombrar una ocurrencia del objeto de datos. Describir la ocurrencia. Hacer referencia a otra ocurrencia en otra tabla. Se debe definir uno o más atributos como un identificador; es decir, el atributo identificador se convierte en una “clave” cuando se desea encontrar una ocurrencia del objeto de datos. En algunos casos, los valores para el o los identificadores son únicos, aunque esto no es un requisito. El conjunto de atributos apropiado para un objeto de datos se determina mediante la comprensión del contexto del problema.

2.3. Relaciones Los objetos de datos están conectados entre sí de muchas maneras diferentes. Por ejemplo dos objetos de datos, empresa y persona, pueden representarse como se muestra en la

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

figura 5 se establece una conexión entre empresa y empleado debido a que los objetos se relacionan entre sí. ¿En este caso cuales son las relaciones? La respuesta se determina entendiendo el papel de las empresas y de los empleados dentro del contexto del software que se construirá. Se puede definir un conjunto de parejas objeto/relación que definan las relaciones relevantes. Diagramas de Entidad-Relación, es una herramienta de modelado de datos que describe las asociaciones que existen entre las diferentes categorías de datos dentro de un sistema de empresa o de información. Todo sistema contiene datos, y en la mayoría de las veces muchos datos. Los datos describen cosas tangibles, funciones, sucesos o lugares de interés para una empresa o sus trabajadores. Por ejemplo:

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Una empresa tiene contratado un empleado Un empleado está empleado para una empresa Las relaciones tiene y está empleado para una empresa definen las conexiones relevantes entre empresa y empleado.

2.4. Cardinalidad y modalidad Los elementos del modelo de datos, objetos de datos, atributos y relaciones ofrecen la base para entender el dominio de información de un problema. También es necesario comprender información adicional relacionada con estos elementos básicos. Hasta aquí hemos relacionados un par que establece que el objeto A se relaciona con el objeto B esto no proporciona suficiente información para los propósitos de los ingenieros de

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

software. Se debe entender cuántas ocurrencias del objeto A están relacionadas con cuántas ocurrencias del objeto B. Esto conduce al modelado de datos llamado cardinalidad. El modelo de datos debe ser capaz de representar el número de ocurrencias de los objetos en una relación dada. Cardinalidad, es la especificación del número de ocurrencias de un objeto que puede relacionarse con el número de ocurrencias de otro objeto. Ejemplo Un objeto puede relacionarse solo con otro objeto (relación 1:1). Un objeto puede relacionarse con muchos objetos (relación 1:N). Un número de ocurrencias de un objeto puede relacionarse con algún otro número de ocurrencias de otro objeto (relación M:N). La cardinalidad también define el número máximo de objetos que puede participar en una relación. Restricciones de cardinalidad, El término restricciones de cardinalidad se refiere a la restricción de la cantidad de elementos que se pueden asociar con otro Diagramas de entidad-relación (base fundamental del modelo de datos)

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3. Análisis Orientado A Objetos Algunas de las ideas fundamentales que se encuentran en la tecnología orientada a objetos son: Objetos y clases (una clase es la implementación de un tipo de objeto). Métodos (los métodos especifican la forma en que se controlan los datos de un objeto) Solicitudes (para que un objeto haga algo le enviamos una solicitud. Esta hace que se produzca una operación. La operación ejecuta el método apropiado y, de manera opcional produce una respuesta. El mensaje que constituye la solicitud contiene el nombre del objeto.) Herencia (una clase implanta el tipo de objeto. Una subclase hereda propiedades de su clase padre; una subclase hereda propiedades de las subclases; etc. Una subclase puede heredar la estructura de datos y los métodos, o algunos de los métodos, de su superclase.) Encapsulado (conjunto de datos y métodos. El objeto esconde sus datos de los demás objetos y permite el acceso a los datos mediante sus propios métodos. Esto recibe el nombre de ocultamiento de la información) Ahora definamos que es objeto: Objeto, son todas aquellas cosas a la que se aplica un concepto. Un objeto podría ser real o abstracto por ejemplo: Una factura. Una organización. Una pantalla con la que interactúa un usuario. Una figura en un programa de dibujo. Un avión El vuelo de un avión. Una reservación aérea. Un proceso para llenar un pedido. Un icono en la pantalla al que un usuario puede apuntar y “abrir”. El objetivo del análisis orientado a objetos es definir todas las clases relevantes para el problema y que deben resolverse. Esto se logra llevando a cabo algunas tareas: Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero de software. Deben identificarse las clases (es decir, se definen los atributos y métodos). Se define una jerarquía de clases. Deben representarse las relaciones de objeto a objeto (conexiones entre objetos). Debe modelarse el comportamiento entre objeto. Las tareas de 1 a 5 se vuelven aplicar de manera iterativa hasta que el modelo esté completo.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.1. Modelo Basado En Escenarios El éxito de un sistema o producto basado en computadora se mide en muchas formas, la satisfacción del usuario encabeza la lista. Si los ingenieros de software entienden la manera en que los usuarios finales y otros actores quieren interactuar con el sistema, el equipo de software será capaz de caracterizar en forma apropiada los requisitos y construir modelos significativos de análisis y diseño. Por tanto, el modelado del análisis con UML. Comienza con la creación de escenarios en la forma de casos de uso, diagramas de actividad y diagrama de carril.

3.2. Escritura de casos de uso Un caso de uso captura las interacciones que ocurren entre los productores y consumidores de información y del sistema en sí mismo. El concepto de un caso de uso es relativamente fácil de entender: describe un escenario de uso específico en un lenguaje directo desde el punto de vista de un actor definido. Como puede saberse 1) ¿sobre qué escribir? 2), ¿cuánto escribir acerca de ello? 3), ¿qué tan detallada debe ser la descripción?, y 4) ¿Cómo organizar la descripción? Estas son las preguntas que deben contestarse para que los casos de uso tengan un valor como herramienta para el modelado del análisis. ¿Sobre qué escribir? Las dos primeras tareas de la ingeniería de requisitos inicio y obtención proporcionan la información necesaria para comenzar a escribir casos de uso. Las reuniones para la recopilación de requisitos, despliegue de la función de calidad (QFD) y otros mecanismos para la ingeniería de requisitos se utilizan para identificar a los interesados, definir el alcance del problema, especificar las metas operativas globales, esquematizar todos los requisitos funcionales conocidos y describir los objetos que manipulará el sistema. El desarrollo de una serie de casos de uso se comienza haciendo una lista de las funciones o actividades que realiza un actor específico. Estas se pueden obtener por medio de conversaciones con los clientes o usuarios finales, o mediante una evaluación de los diagramas de actividad.

3.3. Ayudas Audiovisuales Desarrollo de un escenario de uso preliminar El escenario: una sala de reuniones para la recopilación Reunión: de requisitos. El moderador establece el orden en la Los actores: Juan José Salazar, Arturo Pérez, miembros reunión. Se establecen fechas y hora del equipo de software; Juan Carlos Franco, gerente de para cada reunión, en cada reunión ingeniería de software; dos miembros de mercadeo; un se levantan actas que sirven como representante de ingeniería de producto; y un moderador. inicio para la posterior reunión.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

3.4. Desarrollo de un diagrama de actividad Un diagrama de actividad en UML complementa el caso de uso al proporcionar una representación grafica del flujo de iteraciones dentro de un escenario específico. Un diagrama de actividad utiliza rectángulos redondeados para indicar una función específica del sistema, flecha para representar el flujo a través del sistema, rombos de decisión para mostrar una ramificación por decisión.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Esquemas diseñado por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

En la figura 7 se muestra un diagrama de actividad para la función de AEA-DVE (Acceso a equipos de ayuda audiovisuales – Despliegue de vistas de equipos). Nota: los diagrama de actividad agrega detalles adicionales que no se mencionan de forma directa pero si implícita en el caso de uso. Por ejemplo, un usuario puede intentar ingresar la idUsuario y la contraseña sólo un número limitado de veces. Esto se representa mediante un rombo de decisión debajo de la opción para reingreso.

3.5. Diagramas de carril El diagrama de carril de UML es una variación útil del diagrama de actividad, debido a que permite al modelador la representación del flujo de actividades descritas por el caso de uso y, al mismo tiempo, que actor o clase de análisis tiene la responsabilidad de la acción descrita mediante un rectángulo de actividad. Las responsabilidades se representan como segmentos paralelos que dividen el diagrama en forma vertical, como los carriles de un cultivo de café.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Como pueden ver existen tres clases de análisis Administrador, Equipos y Interfaz con responsabilidades directas o indirectas en el contexto del diagrama de actividad mostrado en la figura 3.7. Respecto a la figura 3.8, el diagrama de actividad se reorganiza de forma que las actividades asociadas con una clase de análisis particular pertenezcan al carril correspondiente a dicha clase. Por ejemplo, la clase Interfaz representa la interfaz con el usuario de acuerdo con la visión del administrador. El diagrama de actividad considera dos opciones que son responsabilidad de la interfaz: opción para el reingreso y opción para otra vista. Estas opciones y las decisiones asociadas con ellas pertenecen al carril de Interfaz.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4. Modelado Orientado Al Flujo El modelado de datos orientado al flujo es una las tareas de análisis utilizadas con mayor frecuencia en la actualidad. Aunque el diagrama de flujo de datos (DFD) y la información relacionada no son una parte formal de UML, pueden utilizarse para complementar los diagramas en UML y proporcionar un conocimiento adicional de los requisitos y el flujo del sistema. Los diagramas de flujo de datos (DFD) tienen una visión del sistema del tipo EntradaProceso-Salida (E-P-S). Esto es, los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento, y los objetos de datos resultantes fluyen al exterior del software. Los objetos de datos se representan mediante flechas etiquetadas y las transformaciones se representan mediante círculos llamados procesos o burbujas. El DFD se representa en forma jerárquica. Esto es, el primer modelo de flujo de datos llamado diagrama de flujo de datos nivel cero o diagrama general de contexto representa el sistema como un todo. Los diagramas de flujo de datos posteriores refinan el diagrama de contexto, ya que proporcionan una cantidad creciente de detalles con cada nivel subsiguiente. El modelado orientado al flujo o estructurado contiene los siguientes elementos: Diagrama de flujo de datos Los datos son la guía de las actividades de la empresa. El análisis de un sistema conoce el papel que tienen los datos de la empresa en la organización. Seguir el flujo de los datos por los procesos de la empresa, que es la finalidad del análisis de flujo de datos, les dice mucho a los analistas sobre cómo se alcanzan los objetivos de la organización. Los diagramas de flujo de datos, como su propio nombre lo indica, son un sistema de procesos Diagrama de estructura de datos Una estructura de datos es un conjunto de datos que están relacionados entre sí y que describen en forma colectiva un componente del sistema. Por ejemplo, la estructura de datos FACTURA está definida como algo que consiste en datos que influyen: Número de la factura La fecha de la factura Cliente Dirección Teléfono E-mail Móvil Detalles de los artículos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Diccionario de datos Es la lista de todos los elementos incluidos en el conjunto de los diagramas de flujo de datos que describen un software. El diccionario de datos se desarrolla durante el análisis de flujo de datos y ayuda al ingeniero de software en la determinación de los requerimientos de sistemas.

4.1. Creación de un modelo de flujo de datos El DFD permite que el ingeniero de software desarrolle modelos del dominio de información y del dominio funcional al mismo tiempo. A medida que el DFD se refina hacia grados mayores de detalle, el analista desempeña una descomposición funcional implícita del sistema. Al mismo, la expansión del DFD resulta en un refinamiento de datos mientras se mueve hacia los procesos que incorporan la aplicación. Ayudas que presentan los diagramas de flujo de datos: El diagrama de flujo de datos nivel 0 debe representar al software como un solo proceso La entrada y la salida primaria deben establecerse con cuidado. La expansión debe comenzar por el aislamiento de procesos, objetos de datos y almacenamientos de datos candidatos a ser representados en el siguiente nivel. Todas las flechas y procesos se deben rotular con nombres significativos. Se debe mantener la continuidad del flujo de información al cambiar de nivel a nivel. La expansión de los procesos debe hacerse una por una. (Esto ocurre cuando el analista intenta mostrar muchos detalles demasiado pronto o representar aspectos de procedimiento del software en lugar de elementos del flujo de información).

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

El uso del DFD y la notación relacionada se ilustra en la figura 9 donde se muestra un DFD al nivel de contexto para la función de reserva de ayudas didácticas. El DFD de nivel 0 ahora se expande a un modelo de flujo de datos de nivel 1. Para lograr esto, se hace un análisis gramatical sobre la narrativa que describe el proceso a nivel de contexto. Esto es, se aíslan todos los sustantivos y verbos en la narrativa de procesamiento de reservas didácticas obtenido en la recopilación de requisitos. En relación con el análisis gramatical comienza a surgir un patrón. Los verbos son los procesos de reservas didácticas; esto es, al final pueden presentarse como procesos en un DFD subsecuente. Los sustantivos son entidades externas (rectángulos), objetos o elementos de datos (flechas) y almacenamientos de datos (líneas dobles o paralelas). Los sustantivos y verbos se pueden asociar de distintas formas entre sí. Por ejemplo, a cada solicitud de reserva se le asigna un número es un atributo del objeto de datos solicitud de reserva. Entonces, al realizar un análisis gramatical sobre la narrativa de procesamiento para un proceso en cualquier nivel del DFD, se puede generar mucha información útil acerca de cómo proceder con la expansión para el siguiente nivel.

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

En la figura 10 se presenta un DFD de nivel 1 para la cual se ha utilizado esta información. El proceso al nivel de contexto mostrado en la figura 9 se ha expandido a cuatro procesos obtenidos de un análisis gramatical. De manera similar, el flujo de información entre los procesos en el nivel 1 ha sido obtenido del análisis. Como pueden ver se mantiene la continuidad del flujo de información entre los niveles 0 y 1. Los procesos representados en el DFD de nivel 1 se expanden después hacia niveles más bajos. Poe ejemplo, es posible expandir el proceso solicitud de reserva hacia un DFD de nivel 2 como se muestra en la figura 11. De hecho, debe señalarse que se mantiene la continuidad del flujo de información entre los niveles.

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

La expansión de los DFD continúa hasta que cada proceso realiza una sola función; es decir, hasta que el círculo que representa el proceso desempeñe una función que pueda implementarse con facilidad como un componente del programa.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

4.2. Creación de un modelo de control de flujo En muchas tipos de aplicaciones el modelo de datos y el diagrama de flujo de datos son todo lo que se necesita para obtener una visión significativa de los requisitos del software. Sin embargo, existen muchas aplicaciones que están guiadas por eventos en lugar de datos, que producen información de control en lugar de reportes, y que procesan información con un especial interés por el tiempo y el rendimiento. Estas aplicaciones requieren aplicar el modelado control de flujo, además del modelado de flujo de datos. Un evento o elemento de control se implementa como un valor booleano (por ejemplo, verdadero o falso, encendido o apagado, 1 o 0) o una lista discreta de condiciones (vacio, saturado, lleno).

4.3. Especificación de control La especificación de control (EC) representa el comportamiento del sistema en el nivel en el cual está referido de dos maneras diferentes: La EC contiene un diagrama de estado que es una especificación secuencial del comportamiento. Contiene una tabla de activación del programa: una especificación combinatoria del comportamiento. La EC describe el comportamiento del sistema, pero no brinda información acerca del trabajo interior de los procesos que activa.

4.4. Especificación de procesos La especificación de proceso (EP) se utiliza para describir todos los procesos del modelo de flujo que aparecen en el nivel final de expansión. El contenido de la especificación de proceso puede incluir texto narrativo, una descripción en lenguaje de diseño de programas (LDP) del algoritmo de proceso, ecuaciones matemáticas, tablas, diagramas o graficas. Al proporcionar una EP para acompañar cada proceso en el modelo de flujo, el ingeniero de software crea una “miniespecificación” que puede servir como guía para el diseño del componente del software que implementará el proceso.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5. Modelado Basado En Clases El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones. El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstracción: Clasificación / Instanciación Composición / Descomposición Agrupación / Individualización Especialización / Generalización La clasificación es uno de los mecanismos de abstracción más utilizados. La clase define el ámbito de definición de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por instanciación de las clases. Cada clase se representa en un rectángulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son: (-) Privado: es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++) (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original. (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación) En las secciones siguientes se presenta una serie de directrices que ayudan a identificar las clases y objetos, atributos, operaciones, paquetes, modelos CRC y diagramas de colaboración.

5.1.1. Identificación de clases de análisis Al observar al interior de una sala se verá que existe un conjunto de objetos físicos que pueden identificarse, clasificarse y definirse con facilidad (en términos de atributos y operaciones). Pero cuando se observa el espacio del problema de una aplicación de software, es posible que las clases y los objetos sea un poco más difícil de comprender.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Al examinar el enunciado del problema se puede iniciar la identificación de clases al realizar un “análisis gramatical” sobre las narrativas desarrolladas para el sistema que se va a construir o de los casos de uso. Las clases se determinan al subrayar cada sustantivo e introduciéndolas en una tabla. Los sinónimos deben anotarse. Si la clase se requiere para implementar una solución, entonces es parte del espacio de solución; de lo contrario, si una clase sólo se necesita para describir una solución es parte del espacio del problema. Las clases se manifiestan en una de las siguientes formas: Entidades externas (por ejemplo, otros sistemas, dispositivos, personas) que producen o consumen información que usará un sistema basado en computadora. Cosas (por ejemplo, reportes, listados, letras, señales) que son parte del dominio de la información para el problema. Papeles (por ejemplo, gerente, ingeniero, personal de ventas) que desempeñan personas que interactúan con el sistema. Organizaciones (por ejemplo, división, grupo, equipo) relevantes para alguna aplicación. Sucesos o eventos (por ejemplo, una transferencia de propiedad) que ocurren dentro del contexto de la operación del sistema. Sitios (por ejemplo, el piso de manufactura o el puerto de carga) que establecen el contexto del problema y la función global del sistema. Estructuras (por ejemplo, sensores, vehículos o computadoras) que definen una clase de objetos o clases de objetos relacionados. Para ilustrar la forma en que las clases de análisis pueden definirse durante las primeras etapas del modelado, se utiliza de nuevo la función de Reserva ayudas didácticas. Para la función de reservas. Al extraer los sustantivos se puede proponer una serie de clases potenciales: Clase potencial Usuario Administrador Instalación Sistema (alias sistema de reservas) Número Contraseña Equipo Aula

Clasificación general entidad externa entidad externa ocurrencia cosa no objeto, atributo de la solicitud cosa cosa cosa

La lista podría extenderse hasta que todos los sustantivos en la narrativa del procesamiento hayan sido considerados. Obsérvese que cada entrada en la lista ha sido llamada como un objeto potencial. Coad y Yourdon sugieren seis características de selección que se deben usar cuando un analista considera cada clase potencial para incluirla en el modelo de análisis:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Información referida. La clase potencial será útil durante el análisis sólo si la información acerca de ella debe recordarse para que el sistema pueda funcionar. Servicios requeridos. La clase potencial debe tener un conjunto de operaciones identificables que pueden cambiar el valor de sus atributos de alguna manera. Atributos múltiples. Durante el análisis de requisitos el enfoque debe estar en la información (Nota: una clase con un solo atributo puede, ser útil durante el diseño, pero probablemente es mejor representarla como un atributo de otra clase durante la actividad de análisis). Atributos comunes. Es posible definir un conjunto de atributos para la clase potencial, y estos atributos pueden aplicarse en todas las instancias de la clase. Operaciones comunes. Es posible definir un conjunto de operaciones para la clase potencial, y estas operaciones pueden aplicarse en todas las instancias de la clase. Requisitos esenciales. Las entidades externas que aparecen en el espacio del problema, y que producen o consumen información esencial para la operación de cualquier solución para el sistema, se definirán casi siempre como clases en el modelo de requisito.

5.1.2. Especificación de atributos Los atributos son los que definen la clase, lo cual da claridad del significado de la clase en el contexto del espacio del problema. Esto se ilustra considerando la clase Usuario definida para reservas didácticas. Estos elementos de datos compuestos se pueden representar de la siguiente manera: Información de identificación = ID del usuario + Nombre + Dirección + Numero teléfono

5.1.3. Definición de operaciones Las operaciones definen el comportamiento de un objeto. Estas se dividen en tres categorías: Operaciones que manipulan los datos de alguna manera (por ejemplo, al agregar, borrar, modificar, seleccionar). Operaciones que realizan un cómputo. Operaciones que preguntan acerca del estado de un objeto. Operaciones que monitorean un objeto para la ocurrencia de un evento de control. Estas funciones se ejecutan al operar sobre atributos o asociaciones. Por lo tanto, una operación debe tener “conocimiento” de la naturaleza de los atributos y asociaciones de la clase.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Esquema diseñado por: Manuel Blanco Palencia. Octubre del 2008

Ejemplo A continuación se mostrará un Proyecto, Pedidos y Cuentas por Cobrar, modelado bajo los dos enfoques: 1. Análisis Estructurado 2. Análisis Orientado a Objeto

5.2. Enfoque Estructurado

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

5.3. Descripciones Del Proceso De Primer Nivel

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

5.4. Modelo Relacional – Pedidos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

5.5. Enfoque Orientado A Objeto

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

Esquemas realizados por: Manuel Blanco Palencia. Octubre del 2008

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

6. UML (Lenguaje Unificado De Modelado) UML es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. Objetivo de UML son muchos los objetivos de UML aquí se presentan algunos Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender. Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción. Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados. Documentar: Los propios elementos gráficos sirven como documentación del sistema des-arrollado que pueden servir para su futura re-visión. Un modelo UML está compuesto por tres clases de bloques de construcción: Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.) Relaciones: Relacionan los elementos entre sí. Diagramas: Son colecciones de elementos con sus relaciones.

6.1. Modelado de objetos En la especificación del UML se puede comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descrito por uno o más modelos, posiblemente desde distintos puntos de vista. Una parte del UML define, entonces, una abstracción con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propósito). El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

100

Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir un edificio el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT , por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: El modelo de objetos, que describe la estructura estática; El modelo dinámico, con el que describe las relaciones temporales entre objetos; El modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta. Los modelos, al no ser una representación que incluya todos los detalles de los originales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología OMT, los modelos permiten una mejor comunicación con el cliente por distintas razones: Es posible enseñar al cliente una posible aproximación de lo que será el producto final. Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado. Reducen la complejidad del original en subconjuntos que son fácilmente tratables por separado. Se considera un modelo completo de la realidad cuando este captura los aspectos importantes del problema y omite el resto. Los lenguajes de programación que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificación total con detalles que no son importantes para el algoritmo que están implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del sistema y una unión lo describe de forma completa. En esta técnica de modelado se utilizó una aproximación al proceso de implementación de software habitual donde se utilizan estructuras de datos (modelo de objetos), las operaciones que se realizan con ellos tienen una secuencia en el tiempo (modelo dinámico) y se realiza una transformación sobre sus valores (modelo funcional). UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

101

informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se desea representar para obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.

6.2. Artefactos para el Desarrollo de Proyectos Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripción o un software. Los artefactos de UML se especifican en forma de diagramas, éstos, junto con la documentación sobre el sistema constituyen los artefactos principales que el modelador puede observar. Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas gráficos para obtener estos distintos puntos de vista de un sistema: Diagramas Diagramas Diagramas Diagramas

de de de de

Implementación. Comportamiento o Interacción. Casos de uso. Clases.

Ejemplo de algunos de los diagramas que utiliza UML.

6.3. Diagramas de Implementación Los diagramas de implementación muestran la estructura del sistema en tiempo de ejecución. En un diagrama de este tipo se puede conocer cómo se configurarán e implementarán los elementos de hardware y software que forman una aplicación. Incluyen la estructura del código fuente y la implementación. Los diagramas de implementación constan de nodos (nodo: en un diagrama de implementación, un objeto físico de tiempo de ejecución que representa un recurso de proceso. Los nodos suelen ser dispositivos informáticos pero también pueden representar recursos humanos o mecánicos.), componentes (componente: en diagramas de componentes e implementación, una unidad distribuible de implementación en un sistema. Por ejemplo, un componente puede representar un módulo físico de código (fuente, binario o ejecutable) o un documento en un sistema humano.) y las relaciones entre ellos. Existen dos tipos: Diagramas de componentes, Diagrama de plataformas despliegue

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

102

6.4. Diagramas de componentes Los diagramas de componentes son diagramas de implementación que muestran la estructura del propio código. Un diagrama de componentes consta de componentes (componente: en diagramas de componentes e implementación, una unidad distribuible de implementación en un sistema. Por ejemplo, un componente puede representar un módulo físico de código (fuente, binario o ejecutable) o un documento en un sistema humano.), como archivos de código fuente, código binario, ejecutables o bibliotecas de vínculos dinámicos (DLL), conectados mediante dependencias (dependencia: relación entre dos elementos que indica que los cambios efectuados en el de destino pueden ocasionar cambios en el de origen.). Utilice un diagrama de componentes para dividir un sistema en componentes uniformes. Normalmente, cada componente de un diagrama de este tipo se documenta con más detalle en un diagrama de casos de uso (caso de uso: en un diagrama de caso de uso, representación de un conjunto de eventos que se generan cuando un actor utiliza un sistema para completar un proceso. Normalmente, un caso de uso es un proceso relativamente largo, no un paso o una transacción individual.) o de clases (clase: en un diagrama de estructura estática, un conjunto de objetos con estructura, comportamiento y relaciones similares. Las clases se declaran en diagramas de clases (de estructura estática) y representan conceptos en los sistemas que se están modelando.).

6.5. Diagrama de plataformas o despliegue Los diagramas de plataformas o despliegue, muestra la configuración de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecución y los objetos que existen en tiempo de ejecución. En este tipo de diagramas intervienen nodos, asociaciones de comunicación, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto físico en tiempo de ejecución, es decir una máquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formada por otros componentes.

6.6. Diagramas de Interacción o Comportamiento Los diagramas de interacción o comportamiento, muestran las interacciones entre objetos ocurridas en un escenario del sistema. Hay varios tipos: Diagrama Diagrama Diagrama Diagrama

de de de de

secuencia. colaboración. estado. actividad.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

103

6.7. Diagrama de secuencia Los diagramas de secuencia, muestran las interacciones entre un conjunto de objetos, ordenados según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento. En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. Existen distintos tipos de mensajes según cómo se producen en el tiempo: simples, síncronos, y asíncronos. Los diagramas de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición, que se especifica en el diagrama.

Esquemas realizados por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

104

La dimensión vertical de un diagrama de secuencia representa el tiempo, que transcurre a medida que se avanza hacia abajo. La dimensión horizontal representa los diferentes actores u objetos. A continuación aparece la explicación de cada uno de los puntos, (numerales) que conforman el diagrama anterior, Diagrama de Secuencia: 1. Los objetos representan una vista de una clase del servicio de directorio. Los objetos representan recursos concretos de la red y tienen valores asignados a sus propiedades se representan como líneas de vida del objeto. Línea de vida de un objeto en un diagrama de secuencia representa la existencia de un objeto en una hora concreta. Si el objeto se crea o se destruye durante el periodo de tiempo que representa el diagrama, a continuación la línea de vida se detiene o comienza en el punto adecuado. 2. Las flechas representan mensajes, en un diagrama de secuencia, mensaje es la comunicación que se establece entre objetos para transmitir información y resultado de una acción. Un mensaje se representa mediante una flecha horizontal entre objetos. Un objeto también puede enviarse mensaje así mismo. 3. En un diagrama de secuencia, activación es el periodo durante el que un objeto o actor realiza una acción. La activación se representa mediante un rectángulo estrecho. 4. Los mensajes de retornos se muestran con líneas entre cortadas

6.8. Diagrama de colaboración Un diagrama de colaboración representa una colaboración, que es un conjunto de funciones de objetos relacionados en un contexto determinado, y una interacción, que es un conjunto de mensajes intercambiados entre los objetos para lograr una operación o resultado determinado. Se trata de un diagrama de interacción que muestra cómo colaboran entre ellos un grupo de objetos, para un evento de sistema definido por un caso de uso. A diferencia de un diagrama de secuencia, un diagrama de colaboración muestra relaciones entre funciones de objeto y no expresa tiempo como una dimensión independiente. Por tanto, los mensajes de un diagrama de colaboración se numeran para indicar su secuencia. Los diagramas de secuencias y los diagramas de colaboración expresan información similar, pero en forma distinta. En los diagramas de colaboración se encuentran los objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad. Un enlace es una instancia de una asociación que conecta dos objetos de un diagrama de colaboración. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

105

Los diagramas de interacción indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un mensaje desde un objeto a otro, si entre ellos existe un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples, sincrónicos, balking , timeout y asíncronos. Durante la ejecución de un diagrama de colaboración se crean, se destruyen objetos y enlaces.

Esquemas realizados por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

106

A continuación aparece la explicación de cada uno de los puntos, (numerales) que conforman el diagrama anterior, Diagrama de Colaboración:

1. Función de clasificador, la cadena del indicador del objeto, esta subrayada para indicar

que el objeto es una instancia. También puede incluir el nombre del objeto ante de los dos puntos. 2. Función asociación, indican relaciones y también pueden indicar la explorabilidad con puntos de flechas. 3. Numero de mensajes de procedimiento de acuerdo con el anidamiento de las llamadas. 4. El primer mensaje siempre procede del exterior del contexto que se va a incluir en el diagrama.

6.9. Diagramas de actividad Un diagrama de actividad es un caso especial de diagrama de estado en el que todos los estados son estados de acción y el flujo de control se desencadena al finalizar las acciones en el estado de origen. Relacionado con una clase o caso de uso determinado, un diagrama de actividad describe el comportamiento interno de un método. Un diagrama de actividad se utiliza para representar el flujo controlado por acciones generadas internamente. Utilice un diagrama de estado para representar un flujo en respuesta a eventos externos. Los diagramas de actividad le ayudan a percibir y documentar actividades paralelas y simultáneas. Esto los convierte en una herramienta excelente para modelar el flujo de trabajo, analizar casos de uso y tratar aplicaciones de subproceso múltiple.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

107

Esquemas realizados por: Manuel Blanco Palencia. Octubre del 2008

A continuación aparece la explicación de cada uno de los puntos, (numerales) que conforman el diagrama anterior, Diagrama de Actividad: 1. El estado inicial es el estado de un objeto antes de que ningún evento del diagrama haya actuado en el. 2. Un estado de acción es un tipo de estado que representa una actividad finalizada. 3. Se produce una transición a partir de un estado de acción cuando se finaliza la acción interna de dicho estado. 4. Se utiliza una transición de combinación para indicar actividades simultáneas que deben finalizarse antes de que se ejecute la siguiente actividad. 5. Etiquetas con condiciones de protección y expresiones de acción. 6. Se utiliza una transacción en marquilla para indicar actividades que pueden producirse en paralelo.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

108

7. El estado final representa la conclusión de la actividad en la situación que representa el diagrama. }

6.10. Diagramas de estado Los diagramas de estado, representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo que se puede denominar en conjunto, una máquina de estados. Un estado en UML es cuando un objeto o una interacción que satisface una condición, desarrolla alguna acción o se encuentra esperando un evento. Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: Simples (normales y reflexivas) Complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transición. Como en todas las metodologías OO se envían mensajes, en este caso es la acción de la que puede enviar mensajes a uno o varios objetos destino

Esquemas realizados por: Manuel Blanco Palencia. Octubre del 2008

A continuación aparece la explicación de cada uno de los puntos, (numerales) que conforman el diagrama anterior, Diagrama de Estado: 1. El estado inicial es el estado de un objeto antes de que ningún evento del diagrama haya actuado en el.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

109

2. Un estado representa un instante en la vida de un objeto (objeto: representa una vista de una clase del servicio de directorio. Los objetos representan recursos concretos de la red y tienen valores asignados a sus propiedades.). Haga doble clic en una forma Estado para agregar un nombre y enumerar sus acciones y actividades internas. 3. Las transiciones (transición: ruta permitida de un estado a otro.) indican que, en respuesta a un evento, un objeto pasará de un estado a otro y realizará una acción. 4. El evento (evento: en un diagrama de actividad o de gráfico de estados, un evento que desencadena una transición. Cuando se encuentra en un estado o estado de acción determinado, un objeto espera a que se produzca un evento para pasar a un estado distinto.) que desencadena la transición se menciona en la cadena de transición. Haga doble clic en una transición para etiquetarla con una cadena que, además de una firma de evento, también puede incluir una condición de protección (protección: en un diagrama de actividad o de gráfico de estados, una condición que se especifica cuando puede tener lugar un evento. Cuando se dispara un evento, una protección se evalúa sólo una vez.), una expresión de acción, etcétera.

6.11.

Diagramas de Casos de Uso

Los casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos como: un actor es una entidad externa al sistema que se modela y que puede interactuar con él; un ejemplo de actor podría ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes: Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de uso

6.12. Diagramas de Clases Los diagramas de clases representan un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos. Algunos de los elementos que se pueden clasificar como estáticos son los siguientes:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

110

Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un único paquete que contiene el resto del sistema, por tanto, un paquete debe poder anidarse, permitiéndo que un paquete contenga otro paquete. Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, métodos, relaciones y significado. En UML una clase es una implementación de un tipo. Los componentes de una clase son: Atributo. Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos. Operación. También conocido como método, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza. Las clases pueden tener varios parámetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrán definidos según sus parámetros formales. Las plantillas pueden tener especificados los valores reales para los parámetros formales, entonces reciben el nombre de clase parametrizada instanciada. Y se puede usar en cualquier lugar en el que podría aparecer una plantilla. Relacionando las clases se encuentra el término utilidad, que se corresponde con una agrupación de variables y procedimientos globales en forma de declaración de clase, también puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaración de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programación. Metaclase: Es una clase cuyas instancias son clases. Sirven como depósito para mantener las variables de clase y proporcionan operaciones (método de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos). Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementación. Un tipo establece una especificación de comportamiento para las clases. Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo. Relación entre clases: Las clases se relacionan entre sí de distintas formas, que marcan los tipos de relaciones existentes:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

111

Asociación: Es una relación que describe un conjunto de vínculos entre clases. Pueden ser binarias o n-arias, según como se hayan aplicado a dos o más clases. Las relaciones de asociación vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociación (existen otros tipos de roles según la relación a la que identifiquen). Indican la información más importante de las asociaciones. Es posible indicar el número de instancias de una clase que participan en una relación mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociación permiten especificar qué objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociación que determina los valores que indican cuales son los valores que se asociarán. Una asociación se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociación. Existe una forma especial de asociación, la agregación, que especifica una relación entre las clases donde el llamado "agregado" indica él todo y el "componente" es una parte del mismo.

Use una clase de asociación N-aria en un diagrama de estructura estática (diagrama de estructura estática: diagrama que muestra la estructura estática de un modelo, es decir, los elementos que existen (como clases y tipos), la estructura interna de los elementos y sus relaciones entre sí.) para agregar atributos, operaciones y otras propiedades a una asociación, dibujada como clase adjunta a una asociación mediante una línea con guiones, una clase de asociación es, realmente, un elemento de modelado. El elemento tiene un nombre único que puede aparecer en la asociación, en la clase o en ambas. Los extremos de la asociación pueden tener las opciones habituales Composición: Es un tipo de agregación donde la relación de posesión es tan fuerte como para marcar otro tipo de relación. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composición, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos. Una composición es una forma de agregación que indica que una parte puede pertenecer a un todo y que la duración de dicho todo determina la de la parte. Una composición se indica con un rombo relleno en uno de los extremos de la asociación y se puede entender como una colaboración en la que todos los participantes forman parte de un mismo objeto compuesto. Generalización: Cuando se establece una relación de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber más de una clase que se comporte como

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

112

subclase. En un diagrama de estructura estática (diagrama de estructura estática: diagrama que muestra la estructura estática de un modelo, es decir, los elementos que existen (como clases y tipos), la estructura interna de los elementos y sus relaciones entre sí.), una generalización es una relación entre un elemento específico y un elemento general, de modo que el primero sea completamente coherente con el segundo e incluya información adicional (como atributos y asociaciones). Por ejemplo, las clases Polígono, Elipse y Pentágono pueden ser elementos específicos de una clase abstracta más general denominada Forma. Para indicar una generalización, use una línea sólida con una flecha hueca en el extremo que señale al elemento más general. Puede agregar una etiqueta de discriminador a una ruta de generalización. La generalización se suele usar con clases, casos de uso y paquetes, pero también se puede utilizar con otros elementos de UML Dependencia: Una dependencia es una relación entre dos elementos que indica que los cambios efectuados en el elemento de origen pueden ocasionar cambios en el de destino. La notación de las dependencias es una flecha de guiones; el elemento situado en la parte posterior de la flecha depende del elemento de la punta de la misma. Una dependencia relaciona los propios elementos del modelo y no requiere instancias para tener significado. Hay cuatro tipos predefinidos de dependencias y están etiquetados con un estereotipo opcional: traza (traza: tipo de dependencia que indica una relación histórica entre dos elementos que representan el mismo concepto a diferentes niveles semánticos o desde distintos puntos de vista.), perfeccionamiento (perfeccionamiento: tipo de dependencia que indica una relación histórica o de derivación entre dos elementos que comparten una asignación. Es posible enlazar a la dependencia una descripción de la asignación en una nota.), uso (uso: tipo de dependencia que indica que un elemento requiere la presencia de otro para implementarse o funcionar correctamente.) y enlace (enlace: tipo de dependencia que indica un enlace de parámetros de una clase con parámetros, o plantilla, con valores reales para crear un elemento enlazado, o sin parámetros.).

6.13. Relación de Refinamiento Es una relación entre dos elementos donde uno de ellos especifica la forma completa al otro que ya ha sido especificado con cierto detalle. Nuevas características del UML Además de los conceptos extraídos de métodos anteriores, se han añadido otros nuevos que vienen a suplir carencias antiguas de la metodología de modelado. Estos nuevos conceptos son los siguientes:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

113

Definición de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensión del modelo. Responsabilidades. Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones. Tareas y procesos. Distribución y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA). Patrones/Colaboraciones. Diagramas de actividad (para reingeniería de proceso de negocios) Clara separación de tipo, clase e instancia. Refinamiento (para manejar relaciones entre niveles de abstracción). Interfaces y componentes.

Esquemas realizados por: Manuel Blanco Palencia. Octubre del 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

114

A continuación aparece la explicación de cada uno de los puntos, (numerales) que conforman el diagrama anterior, Diagrama de Secuencia: 1. Para agregar atributos, operaciones y otras propiedades a formas de clase, haga doble clic en una forma para abrir el cuadro de diálogo Propiedades de la clase de UML. 2. Haga doble clic en una asociación para agregar características, como la multiplicidad y explorabilidad. 3. Además del nombre y el tipo que aparecen aquí, los atributos también pueden incluir la visibilidad, un valor inicial, así como especificar si el ámbito es de clase o de instancia. 4. Defina totalmente los parámetros de una operación en un diagrama cuando desee comunicar especificaciones de programación detalladas.

6.14. El Proceso de Desarrollo UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas. UML es un método independiente del proceso. Los procesos de desarrollo deben ser definidos dentro del contexto donde se van a implementar los sistemas.

Patrón de diseño de software que solo ejecuta una acción sobre un objeto cuando el objeto esta en un estado particular Tiempo de espera

Orientación a objeto metodología de Análisis y diseño

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

115

Unidad 4

Diseño de sistemas basado El diseño bajo el enfoque estructurado o sea orientado al flujo de datos es una metodología que utiliza las características del flujo de información para explicar la estructura de programa. Un diagrama de flujo de datos se convierte en una estructura de programa usando una de dos técnicas, como son: análisis de transformación o análisis de transacción.

El análisis de transformación se aplica a un flujo de información que muestra unos senderos claros para los datos entrantes y los salientes. Los diagramas de flujo de datos se convierten en estructuras que asignan control a la entrada, al procesamiento y a la salida, en tres jerarquías de módulos factorizados por separado. El análisis de transacción se aplica cuando un elemento de información hace que el flujo se divida hacia uno de entre muchos caminos. El diagrama de flujo de datos se convierte en una estructura que asigna el control a una subestructura que toma y evalúa una transacción. Las técnicas vistas en esta unidad conducen a una descripción del diseño preliminar del software. Se definen los módulos, se establecen las interfaces y se desarrollan las estructuras de datos. Estas representaciones del diseño forman la base de todo el trabajo posterior de desarrollo. El diseño orientado a objetos crea un modelo del mundo real que puede ser realizado en software. Los objetos proporcionan un mecanismo para representar el alcance de la información, mientras que las operaciones describen el procesamiento asociado con el alcance de información. Los mensajes proporcionan el medio por el que se invocan las operaciones. La orientación a objetos es un paradigma que está de moda para el desarrollo de software. En un programa orientado a objetos se tiene a un conjunto de objetos colaborando entre ellos. Un objeto es una abstracción conceptual del mundo real que se puede traducir a un lenguaje de programación orientado a objetos. Un objeto del mundo real tiene características y comportamientos, y de la misma manera, un objeto del mundo del software tiene atributos y métodos. Una Clase es una plantilla que define los atributos y métodos a ser incluidos en un tipo de objeto específico. Los objetos también son llamados instancias de la Clase. Los objetos sólo almacenan su estado. Se dice que un objeto tiene estado cuando tiene valores en sus atributos. Los objetos se comunican entre ellos usando los mensajes. Un mensaje es la invocación de un método del objeto. El enfoque orientado a objetos requiere de una metodología que integre el proceso de desarrollo y un lenguaje de modelamiento con herramientas y técnicas adecuadas

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

117

1. Fundamentos Del Diseño De Software Diseño, es el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física. El objetivo del diseñador es producir un modelo o representación de una entidad que se construirá en etapas posteriores.

1.1. Diseño del software El diseño del software se asienta en el núcleo técnico del proceso de ingeniería del software y se aplica independientemente del paradigma de desarrollo utilizado. Una vez que se han establecido los requisitos del software, el diseño del software es la primera de tres actividades técnicas como son: • • •

Diseño Codificación Prueba

Cada actividad transforma la información de forma que finalmente se obtiene un software para computadora valido.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

118

Diseño de datos, El diseño de datos, trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. El diseño de datos se podría afirmar que es la más importante de las cuatro actividades de diseño realizadas durante la ingeniería del software. El impacto de la estructura de datos sobre la estructura de programas, hace que el diseño de datos tenga una gran influencia en la calidad del software. Diseño arquitectónico, Define la relación entre cada uno de los elementos estructurales del programa. Diseño de la Interfaz, Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. Diseño procedimental, transforma los elementos estructurales en una descripción procedimental del software. Se genera el código fuente y, para integrar y validar el software, se llevan a cabo las pruebas. Nota: las fases de diseño, codificación y prueba absorben el 75% o más del costo del software (excluyendo el mantenimiento) Importancia del diseño, la importancia del diseño del software se puede sentar con una única palabra – calidad. Y la podemos clasificar en: o o o o

El diseño es el proceso en el que se asienta la calidad del desarrollo del software. El diseño produce las representaciones del software de las que puede evaluarse su calidad El diseño es la única forma mediante la cual podemos traducir con precisión los requisitos del cliente en un producto o sistema acabado El diseño de software sirve como base (Figura # 2) de todas las posteriores etapas del desarrollo y de la fase de mantenimiento.

Grafico basado en el texto, Ingeniería del Software de Roger S. Pressman

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

119

Desde el punto de vista de la gestión del proyecto, el diseño del software se realiza en dos pasos: • •

Diseño preliminar Diseño detallado

Diseño preliminar, se centra en la transformación de los requisitos en los datos y la arquitectura del software. Diseño detallado, se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algorítmicas del software. Dentro del contexto de los diseños preliminar y detallado, se llevan a cabo varias actividades de diseño diferentes. Además del diseño de datos, arquitectónico y procedimental, muchas aplicaciones modernas requieren una actividad distinta de diseño de la interfaz. El diseño de la interfaz, establece la disposición y los mecanismos para la interacción hombre – máquina. El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el Software. El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación.

1.2. Calidad del software A lo largo del proceso de diseño, la calidad del diseño resultante se evalúa mediante una serie de revisiones técnicas formales. Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos que garanticen un buen diseño como son: • • •

Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software. El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en elementos que realicen funciones y subfunciones especificas. Un diseño debe contener abstracciones de datos y procedimientos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

120

• •

•

Debe producir módulos que presenten características de funcionamiento independiente. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior. Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software.

Estos criterios no se consiguen por casualidad. El proceso de Diseño del Software exige buena calidad a través de la aplicación de principios fundamentales de Diseño, Metodología sistemática y una revisión exhaustiva. Cuando se va a diseñar un Sistema de Computadoras se debe tener presente que el proceso de un diseño incluye, concebir y planear algo en la mente, así como hacer un dibujo o modelo o mapa.

1.3. Fundamentos del diseño La sabiduría de un desarrollador de software (Ingeniero de software) está en reconocer la diferencia entre obtener un programa que funcione y obtener uno que funcione correctamente. Los conceptos fundamentales del diseño de software proporcionan la base necesaria para que funcione correctamente. Los fundamentos a tener en cuenta son: Abstracción, la abstracción permite concentrarse en un problema al mismo nivel de generalización, independientemente de los detalles irrelevantes de bajo nivel; el uso de la abstracción también permite trabajar con conceptos y términos que son familiares al entorno del problema, sin tener que transformarlos a una estructura no familiar. Refinamiento, este es realmente un proceso de elaboración. Donde se comienza con una declaración de la función (o una descripción de la información) definida a un nivel superior de abstracción. Modularidad, atributo individual intelectualmente manejable.

del

software

que

permite

programa

ser

Arquitectura del software, se refiere a dos características importantes del software de computadora como son: • •

Estructura jerárquica de los componentes procedimentales (módulos) Estructura de los datos

Estructura del programa, representa la organización (comúnmente jerárquica) de los componentes del programa (módulos)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

121

Estructura de datos, es una representación de la relación lógica existente entre los elementos individuales de datos.

1.4. Diseño del sistema El diseño de un sistema de información produce los elementos que establecen cómo el sistema cumplirá los requerimientos identificados durante el análisis de requisitos. A esta etapa se le conoce también con el nombre de Diseño Lógico. El primer paso en el diseño de sistemas es identificar los informes y las salidas que el sistema producirá; a continuación los datos específicos de cada uno de éstos se señalan, incluyendo su localización exacta sobre el papel, la pantalla de despliegue o cualquier otro medio. El diseño también describe los datos calculados o almacenados que se introducirán. Los datos y los procedimientos de cálculo se describen con detalle. Se seleccionan las estructuras de los archivos y los dispositivos de almacenamiento, como son discos o cintas magnéticas o papel. Los procedimientos deben mostrar cómo se van a procesar los datos y cuáles van a ser las salidas. Los documentos que contienen las especificaciones del diseño se pueden representar por medio de los diagramas, tablas y símbolos especiales. El último paso del diseño detallado es pasar la información al grupo de programación para que se inicie el desarrollo del software. El diseño de sistemas es un proceso altamente creativo que en gran medida puede ser facilitado por:

1. Definición sólida del problema. 2. Descripción del sistema existente. 3. Conjunto de requerimientos del nuevo sistema. Diseño significa hacer un mapa, planear o arreglar las partes en un todo que satisfaga los objetivos involucrados. El diseño de sistemas requiere principalmente la coordinación de actividades, los procedimientos de trabajo y la utilización de equipo para alcanzar los objetivos organizacionales. El patrón de diseño de sistemas sigue una técnica iterativa. El diseño de sistemas es un proceso creativo en el que el analista repite a través de varias actividades o procedimientos de trabajo, uno a la vez, investigando mentalmente a través del proceso completo. El analista debe tener en cuenta dos puntos importantes: •

Resuelva un problema a la vez. No se confunda al querer resolver muchos problemas al mismo tiempo.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

122

•

Su nuevo sistema debe tener concordancia con los objetivos y metas generales del área bajo estudio y la empresa en sí.

Los puntos a seguir cuando se diseña un nuevo sistema son:

1. Examine todos los datos posibles. • • • •

Concéntrese y piense en forma creativa. Proporcione diferentes entradas, salidas, operaciones, controles y técnicas de procedimiento. Primero evalúe los procedimientos más importantes. Examine las diversas alternativas.

Otra consideración en la fase de diseño es el control que se debe ejercer desde el sistema. Algunos controles se determinarán por medio de diferentes parámetros de sistemas tales como las aplicaciones y las entradas. Probablemente se necesite diseñar ciertos controles de calidad. Por ejemplo, todas las entradas deben preparase en forma consistente para mantener la confianza del sistema y evitar posibles errores en los procedimientos. Las especificaciones de diseño describen las características del sistema, sus componentes o elementos y la forma en que estos aparecerán ante los usuarios. Para la mayoría de los usuarios, el éxito de un sistema está relacionado con la creencia que tengan sobre sí el sistema tiene las características adecuadas. Los componentes de un sistema de información requerimientos, son el punto principal del diseño.

descritos durante el análisis

Los analistas deben diseñar los siguientes elementos: •

Flujos de datos: Movimientos de datos hacia, alrededor y desde el sistema.

• •

Almacén de datos: Conjuntos temporales o permanentes de datos. Procesos: Actividades para aceptar, manejar y suministrar datos e información. Pueden ser anuales o basadas en computadora. Procedimientos: Métodos y rutinas para utilizar el sistema de información y lograr con ello los resultados esperados. Controles: Estándares y lineamientos para determinar si las actividades están ocurriendo en la forma anticipada o aceptada, es decir, si se encuentran bajo control. Asimismo especificar las acciones que deben emprenderse cuando ocurren problemas o presentan circunstancias inesperadas. Puede incluirse un reporte sobre las excepciones o procedimientos para la corrección de los problemas. Funciones del personal: Las responsabilidades de todas las personas que tienen que ver con el nuevo sistemas incluyendo los usuarios, operadores de computadora y personal de apoyo. Abarca todo el espectro de componentes del sistema, incluso desde la entrada de datos hasta la distribución de salidas o resultados. A menudo, las funciones del personal se establecen en forma de procedimiento.

• •

•

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

123

1.5. Desarrollo del software A menudo los especialistas de sistemas se refieren a esta etapa como el Diseño Físico, en contraste con el Diseño del sistema que se conoce como el diseño lógico. Los desarrolladores pueden instalar o modificar software que se haya comprado (software comercial), o pueden escribir nuevos programas diseñados a la medida; la decisión depende del costo de cada una de las opciones dadas, el tiempo y disponibilidad de los programadores. Los desarrolladores de software son también responsables de la documentación del programa y de incluir los comentarios que expliquen cómo y porqué se utilizó cierto procedimiento. La documentación es esencial para probar el programa y darle mantenimiento una vez que se ha puesto en marcha.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

124

2. Diseño General De Sistemas El diseño de sistemas se refiere a la formulación de especificaciones para el nuevo sistema o subsistema propuesto, de manera que satisfaga los requisitos determinados durante la fase de análisis o ingeniería de requerimientos. Finalmente el diseño de sistemas vendrá a ser una presentación detallada del informe de terminación del análisis de sistemas. El diseño de un sistema de información puede descomponerse en especificaciones físicas y lógicas. •

•

Diseño lógico: representa los componentes del sistema y sus relaciones mutuas, como aparecerían ante los usuarios. Muestra lo que la solución sistemática hará en contraposición con el modo como lo es en la actualidad implantada físicamente. Describe las entradas y salidas, las funciones de procesamiento a realizar, los procedimientos de negocios, los modelos de datos y los controles. Diseño físico es el proceso de traducción del modelo lógico abstracto a un diseño técnico específico para el nuevo sistema. Produce las especificaciones reales para el hardware, software y bases de datos físicas, medios de entrada/salida, procedimientos manuales y controles específicos. Proporciona las especificaciones que transforman el diseño lógico abstracto en un sistema de funciones de hombre y máquinas.

Cuando el analista esté listo para comenzar a diseñar el nuevo sistema, ya deben estar establecidos ciertos elementos. Debe hacer una definición del problema, información general de antecedentes sobre el área bajo estudio, una idea aproximada de las interacciones dentro del área de estudio y con otras áreas, un buen entendimiento del sistema actual, y un conjunto de requerimientos para el nuevo sistema.

2.1. Definiciones de diseño de sistemas. El diseño puede definirse como el acto de delinear, planear, bosquejar y disponer muchos elementos separados, reuniéndolos en un conjunto viable y unificado. Mientras que en la fase de análisis de requisitos responde a preguntas tales como ¿qué está haciendo el sistema? y ¿qué debería hacer para satisfacer las necesidades de los usuarios?, la fase de diseño se ocupa de ¿cómo debe desarrollarse el sistema para que pueda satisfacer esas necesidades? Durante el proceso de diseño, el analista plantea soluciones alternativas y finalmente determina cuál es la mejor. La fase de diseño es de naturaleza técnica, hasta el punto en que el analista debe responder esta pregunta "¿Cómo vamos a hacerlo?". Por otra parte, el diseño también es un arte creativo, hasta el punto en que el analista se pregunta continuamente: ¿qué ocurrirá si...? y ¿por qué no?

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

125

El diseño es pues una solución: es la conversión de los requerimientos en forma que satisfaga las necesidades del usuario. El diseño determina el éxito del sistema. A través del diseño, los ingenieros de software pueden tener gran influencia sobre la efectividad del usuario, ya sea para el manejo de transacciones o para la administración de la organización. Algunos diseños son más efectivos que otros. Mientras que el análisis de requisitos describe lo que un sistema debe hacer para satisfacer los requerimientos de información, el diseño de sistemas muestra cómo el sistema debe de satisfacer este objetivo. El diseño de sistemas de información es el plan general o modelo para ese sistema. Como el plano de un edificio o una casa, tiene todas las especificaciones que dan al sistema su forma y estructura, el diseño de los sistemas de información es una tarea creativa que requiere de imaginación, sensibilidad al detalle y habilidades. Para diseñar un sistema, el ingeniero de software debe conocer ciertos elementos relacionados con los siguientes aspectos: • • • • • •

Los Las Las Los Las Las

recursos de la organización. necesidades de información de los usuarios. necesidades de otros sistemas. métodos de procesamiento de datos. operaciones con los datos. herramientas del diseño.

Para producir el diseño, el ingeniero de software tiene que aplicar el razonamiento y la creatividad a los elementos mencionados.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

126

2.2. Objetivos del Información:

diseño

sistemas

El diseño de sistemas tiene tres objetivos: •

El diseñador de sistemas es responsable de la consideración de otras configuraciones de tecnología para llevar a cabo y desarrollar el sistema tal y como fue descrito por el análisis. Esto puede implicar análisis del desempeño de diferentes elementos de hardware y software capacidades de los sistemas, alternativas de redes y la transportabilidad del hardware de los sistemas.

•

Los diseñadores son responsables por la administración y el control de la realización técnica de los sistemas. Las especificaciones detalladas de programación, la codificación de los datos, la documentación, pruebas y la capacitación, son responsabilidad del equipo de diseño. Además, los diseñadores son responsables del abastecimiento actual del hardware y el software que se necesita para el sistema. o

El diseñador de sistemas detalla las especificaciones del sistema que darán las funciones identificadas durante el análisis de sistemas. Estas especificaciones deben tocar todos los componentes administrativos, organizacionales y tecnológicos de la solución de sistemas.

Especificar los elementos Especificaciones detalladas de diseño que describen las características de un sistema de información: entradas, de diseño lógico salidas, archivos y base de datos y procedimientos. Actividades de soporte Los resultados del empleo del sistema serán de ayuda para la empresa. para mejorar el rendimiento de la empresa Satisfacer los Satisfacer las necesidades de los usuarios en términos de: requerimientos de los usuarios. • Efectuar en forma correcta los procedimientos apropiados. • Presentar en forma apropiada la información. • Proporcionar resultados exactos. • Utilizar los métodos de interacción apropiados. • Proporcionar confiabilidad total. Fácil de usar.

Ingeniería humana favorable: El diseño ergonómico debe ser físicamente cómodo y contribuir a la efectividad y eficiencia del usuario. las Especificar los componentes y funciones con suficiente de detalle para construir el software de aplicación.

Proporcionar especificaciones software. Ajustarse a los estándares El diseño y sus especificaciones deben estar en de diseño concordancia con las reglas prácticas establecidas para la organización.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

127

2.3. Etapas básicas del proceso diseño. En la práctica, la aplicación del proceso de diseño es un esfuerzo repetitivo. A medida que el analista va considerando cada uno de los elementos del proceso, se ve obligado a revisar una y otra vez a reexaminar las estructuras y relaciones establecidas hasta el momento, y a modificarlas para satisfacer la nueva condición. La repetición continúa hasta que han sido consideradas todas las dimensiones del sistema propuesto y se formula la proposición final. Las etapas básicas del proceso de diseño pueden exponerse así: 1. Definir el objetivo del sistema. 2. Desarrollar un modelo conceptual.

Identificar el resultado más importante del sistema. Señalar los datos específicos de entrada necesarios para obtener ese resultado. Describir las operaciones de procesamiento de datos, particularmente los algoritmos lógicos y de cálculo, que deben aplicarse a los datos de entrada para producir la información deseada. Identificar los elementos de entrada que se pueden introducir una sola vez y quedar almacenados para usarlos en operaciones subsecuentes de procesamiento. Seguir efectuando los pasos a, b, c, d para cada resultado requerido y por orden de prioridad hasta haberlos considerado en su totalidad. Establecer un banco de datos que pueda sustentar al sistema en la forma más efectiva.

3. Aplicar restricciones. • •

En base a las restricciones impuestas eliminar los casos extremos de entrada, salida y procesamiento. Señalar los diferentes puntos de control.

4. Definir las actividades de procesamiento de datos. • •

Diseñar los formatos de entrada y salida que mejor se adapten al diseño del sistema. Establecer los métodos de procesamiento y los puntos comunes de los datos.

5. Formular la proposición del diseño del sistema. Analizando específicamente las entradas, las salidas y las actividades de procesamiento por orden de su contribución al logro del objetivo general del sistema, el analista reduce al mínimo el tiempo necesario para llegar a una estructuración del diseño principal.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

128

2.4. Diseño Estructurado

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

129

2.5. Diseño detallado:

2.6. Diseño de salidas (Diseño del sistema de informes y producción de documentos) La salida, se refiere a los resultados e información generados por el sistema. Para muchos usuarios finales, la salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación. En la actividad real, muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada por el sistema bien sea para agilizar su trabajo o para la toma de decisiones. Cuando se diseñan las salidas, los analistas deben realizar lo siguiente: • • • •

Determinar qué información presentar. Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio de salida. Disponer la presentación de la información en un formato aceptable. Decidir cómo distribuir la salida entre los posibles destinatarios.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

130

Para llevar a cabo las actividades antes mencionadas, se requieren decisiones específicas tales como el empleo de formatos ya impresos cuando se preparan reportes, cuántas líneas planear sobre una página impresa o si se debe emplear gráficas y colores. La salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación. En realidad, muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada por el sistema. El diseño de la salida de la computadora debe avanzar en una forma organizada y bien pensada: tiene que desarrollarse correctamente mientras que al mismo tiempo se garantice que cada elemento de la salida está diseñado para que las personas encuentren que el sistema es fácil de emplear. El termino salida se utiliza para denotar cualquier información, ya sea impresa o en una pantalla. Cuando los analistas diseñan la salida: • • •

Identifican la salida específica que es necesaria para satisfacer los requerimientos de la información. Seleccionan los métodos para presentar la información. Crean los documentos, reportes u otros formatos que contienen la información producida por el sistema.

Un sistema de información debe alcanzar uno o más de los siguientes objetivos: • • • •

Expresar información relacionada con actividades pasadas, estado protecciones para el futuro. Señalar eventos importantes, oportunidades, problemas o advertencias. Iniciar una acción. Confirmar una acción.

actual

Un buen diseño de la salida de los sistemas, no puede ser desarrollado en forma independiente del uso que se dará a la salida. En otras palabras, no se puede clasificar como buena una salida estéticamente atractiva o que haga uso de una nueva tecnología, a menos que satisfaga las necesidades de la organización y de sus usuarios. El propio proceso de diseño comienza cuando el ingeniero de software identifica la salida que debe producir el sistema (un proceso que se inicia durante la determinación de requerimientos). Ejemplo: Informe de un estado de cuenta para la organización

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

131

Figura 6: Diseño de salida

2.7. Aspectos importantes de las Salidas Cuatro preguntas, a las que debe darse respuestas en forma completa y apropiada, ayudan a los expertos de diseño de sistemas a comprender mejor lo que debe ser la salida de un nuevo sistema: ¿Quiénes recibirán la salida? El usuario, ¿forma o no parte de la organización?, Quizá los usuarios externos tengan requerimientos específicos que no se pueden cambiar y que dictan los requerimientos de contenido, formato y medio de presentación. Tal vez las organizaciones decidan presentar la misma información en forma diferente cuando ésta es enviada a los usuarios tanto externos como internos. ¿Cuántos detalles son necesarios? Pocos detalles son necesarios para indicarle a alguien que renové una licencia de manejo (nombre, dirección, fecha de renovación, cuota y una identificación de la salida como aviso de renovación). Sin embargo, un informe trimestral de venta de ventas contiene muchos detalles con formatos diferentes que son de ayuda para trasmitir un mensaje (qué sucedió, cómo ocurrió y cuál fue el resultado) a todos los usuarios. Asimismo, la cantidad de datos también sugiere si deben emplear métodos de impresión o de presentación en una pantalla. ¿Cuántos y que tan frecuente es la salida?

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

132

El calendario junto con la oportunidad de la salida, son guías específicas del diseño. Algunas salidas se producen con poca frecuencia y sólo cuando aparecen ciertas condiciones: la emisión del aviso de renovación de licencia puede ocurrir cada 4 años, la emisión de una notificación de pago sucede cuando el saldo de la cuenta está vencido. Sin embargo, la organización puede requerir cada mes una salida que indique todas las licencias que deben renovarse el próximo mes, o una salida cada semana que señale todas aquellas cuentas cuyo saldo se venció durante la semana. ¿Qué método utilizar? ¿Debe ser impresa o presentada en pantalla? Los ejemplos anteriores muestran que la salida impresa se emplea con bastante frecuencia. Sin embargo, si un sistema da respuestas del tipo sí o no a las consultas, a menudo es apropiado presentar la respuesta en una pantalla, algunos sistemas emplean una salida de audio para informarles sobre un nuevo número telefónico o el cambio de éste.

2.8. Diseño de entradas (Diseñar el sistema de recopilación de datos) Las especificaciones de entrada describen la manera en que los datos ingresarán al sistema para su procesamiento. Las características de diseño de la entrada pueden asegurar la confiabilidad del sistema y producir resultados a partir de datos exactos, o también pueden dar como resultado la producción de información errónea. Asimismo, el diseño de la entrada determina sí el usuario puede interactuar con el sistema de manera eficiente. El diseño de la entrada es el enlace que une al sistema de información con el mundo y sus usuarios. Algunos aspectos del diseño cambian, lo que depende si el sistema está orientado hacia lotes o en línea. Pero sin considerar el sistema, existen aspectos generales en la entrada que todos los analistas deben tener en cuenta. El diseño de la entrada consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los pasos necesarios para poner los datos de una transacción en una forma utilizable para su procesamiento, así como la entrada de éstos. La entrada de los datos se logra al instruir la computadora para que los lea ya sea de documentos escritos o impresos, o por personas que los escriben directamente en el sistema. Ejemplo: Entrada desde el sistema

Figura 7: Diseño de entrada

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

133

2.9. Controles de la cantidad de entrada Existen varias razones que explican por qué un buen diseño debe controlar la cantidad de datos en la entrada. •

Las operaciones de preparación y entrada dependen de las personas. Dado que los costos de la mano de obra son altos, los asociados con la preparación e ingreso de los datos también lo son altos. Disminuir los requerimientos de datos puede reducir los costos y ocurrir lo mismo con los costos de mano de obra.

•

La fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitan las computadoras para llevar a cabo sus tareas. De hecho, la computadora quizá permanezca sin hacer nada durante el tiempo en que se preparan los datos y la entrada para su procesamiento. Al disminuir los requerimientos de la entrada, el analista puede acelerar todo el proceso desde la captura de datos hasta que los resultados llegan a manos de los usuarios.

•

Evitar Retrasos. Un retraso en el procesamiento, que es un resultado de las operaciones de preparación o de entrada de datos, recibe el nombre de cuello de botella. Evitar los cuellos de botella debe ser siempre uno de los objetivos que el analista persiga al diseñar la entrada.

•

Evitar errores de datos. En cierto sentido la tasa de errores depende de la cantidad de datos que se manejen, ya que entre más pequeña sea ésta, menores serán las oportunidades para cometer errores. Es usual encontrar en las operaciones de venta al detalle una tasa promedio del 3% de error en las operaciones de entrada de

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

134

datos. Si el volumen de datos es de 5,000 transacciones por semana, entonces se presentarán aproximadamente 150 errores. A pesar de lo anterior, el analista puede reducir el número de errores al disminuir el volumen de datos que deben ingresarse por cada transacción. El analista también puede modificar las tasas de error de una operación a través del diseño de la entrada, ya que la forma en que deben ingresar los datos puede tener efectos sobre la incidencia de los errores. Otro aspecto del control de errores es la necesidad de detectarlos cuando éstos se presentan. Las verificaciones en los programas para entrada de datos, denominadas técnicas de validación de entradas, también descubren errores en la entrada. •

Evitar pasos adicionales. Algunas veces el volumen de transacciones y la cantidad de datos en preparación, o en el trabajo de entrada de datos, es algo que no se puede controlar. Cuando no es posible reducir el volumen de transacciones, el analista debe asegurar que el proceso sea lo más eficiente posible. El analista experimentado también evitará diseños para la entrada que traigan como consecuencia una mayor cantidad de pasos a seguir. El efecto que trae consigo ya sea añadir o quitar un paso cuando se alimentan los cheques al proceso bancario, será multiplicado muchas veces en el transcurso de un día de trabajo.

•

Mantener la sencillez del proceso. Quizá el mejor consejo para los analistas es alcanzar todos los objetivos ya mencionados en la forma más sencilla posible. Obviamente que al incluir tantos controles sobre los errores las personas puedan tener dificultades al emplear el sistema. En otras palabras. el control de los errores puede obstruir la tarea. El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo, proporcionarán métodos para el control de los errores. La simplicidad funciona y es aceptada por los usuarios. En contraste, cuesta trabajo que los usuarios acepten diseños para la entrada que sean complejos o confusos, y no existe ninguna garantía para el éxito al instalar un sistema complejo. En consecuencia, es aconsejable evitar la complejidad cuando hay opciones más sencillas.

•

Validación de la entrada. Los diseños de las entradas tienen como finalidad reducir la posibilidad de cometer errores o equivocaciones durante la entrada de datos. Sin embargo, siempre debe suponer que se presentarán errores. Estos deben detectarse durante la entrada y corregirse antes de guardar los datos o procesarlos. Es mucho más difícil corregir datos equivocados después de almacenarlos que antes de hacerlo. De hecho los datos equivocados se olvidan con frecuencia hasta que alguien utilice un reporte basado en esos datos y cuestiona su exactitud y validez.

Los ingenieros de software deciden sobre los siguientes detalles del diseño de entradas.

1. 2. 3. 4. 5.

Qué datos ingresan al sistema. Qué medios utilizar. La forma en que se deben disponer o codificar los datos. El diálogo que servirá de guía a los usuarios para dar entrada a los datos. Validación necesaria de datos y transacciones para detectar errores.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

135

6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando se presentan errores.

Las decisiones de diseño para el manejo de entradas, especifican la forma en que serán aceptados los datos para su procesamiento por computadora. Los analistas deciden si los datos serán proporcionados directamente, quizá a través de una estación de trabajo, o por el uso de documentos, como talones de venta, cheques bancarios o facturas, donde los datos a su vez son transferidos hacia la computadora para su procesamiento.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

136

3. Diseño de Archivos y Bases de datos Los sistemas de información en las empresas están orientados hacia el uso de archivos y bases de datos. Los datos se acumulan en archivos que son procesados o mantenidos por el sistema. Las bases de datos acumulan los datos de las transacciones y otros tipos de archivos, y están diseñadas para compartir los datos para distintas aplicaciones. Es importante determinar su contenido y elegir un método para organizar los datos. Al mismo tiempo, si las aplicaciones propuestas utilizaran los recursos de la base de datos, el analista debe desarrollar los medios para interactuar con la misma. Las bases de datos permiten compartir los datos entre distintas aplicaciones. Además de la responsabilidad de diseñar archivos, determinar sus contenidos y elegir los métodos apropiados para organizar los datos, los analistas deben diseñar los medios de interacción con las bases de datos de la organización. En la mayoría de los casos, las bases de datos ya estarán disponibles y manejadas por el personal de administración de ésta. Cuando se diseña un sistema de información para el procesamiento de transacciones, a menudo el centro de atención es una entidad. Cuando los analistas y usuarios adquieren experiencia con el sistema de información y surgen nuevos requerimientos de la aplicación, la atención cambia: de ser capaz de recuperar un registro específico, a desarrollar la capacidad de relacionar los registros sobre distintas entidades. Es probable que cambien los requerimientos cuando las empresas quieren más información para las solicitudes de procesamiento. El diseño de archivos incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos de tipo histórico o información de referencia. Entre las decisiones que se toman durante el diseño de archivos, se encuentran las siguientes: • • •

Los datos deben incluirse en el formato de los registros contenidos en el archivo. La longitud de cada registro, con base en las características de los datos que contiene. La secuencia a disposición de los registros dentro del archivo (la estructura de almacenamiento que puede ser secuencial, indexada o relativa).

No todos los nuevos sistemas de información requieren del diseño de todos los archivos utilizados por la aplicación. Por ejemplo, es probable que ya existan archivos maestros porque éstos son utilizados por otras aplicaciones existentes. Muchas de las cuestiones técnicas importantes para el diseño de archivos y bases de datos son objeto de otros cursos. Revisaremos aquellas cuestiones que tengan que ver con las responsabilidades del analista de software. Terminología Básica de Archivos y base de datos:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

137

• •

DATOS: Los elementos individuales de los archivos se llaman datos, también conocidos como campos. Cada dato se identifica por su nombre y tiene un valor específico asociado a él. CAMPOS: un campo es la implementación de un atributo de datos. Los campos son las unidades mínimas de datos que han de almacenarse en un archivo o base de datos.

Existen cuatro tipos de campos susceptibles de ser almacenados: claves primarias, claves secundarias, claves externas y descriptores. •

CLAVES PRIMARIAS: son campos cuyos valores identifican a uno y solo un registro en un archivo. Ejemplo, un CODIGO DE CLIENTE identifica de forma única a un registro de clientes, y un NÚMERO DE PEDIDO identifica únicamente a un registro de pedidos. CLAVES SECUNDARIAS: Son índices alternativos para la identificación de una entidad. Los valores de una clave secundaria pueden identificar a presencias únicas de la entidad o a un subconjunto de todas las presencias de dicha entidad.

Ejemplo, GENERO define dos subconjuntos de la entidad EMPLEADO, los varones y las mujeres. Un archivo puede tener varias claves secundarias. •

CLAVES EXTERNAS: son punteros o enlaces con presencias de archivos diferentes. Una clave externa en una entidad debe ser clave primaria en otra entidad. Las claves externas implantan físicamente las relaciones en un D-E-R.

Ejemplo, un registro de PEDIDO contiene la clave externa CODIGO DE CLIENTE para “apuntar” al registro de cliente al que está asociado el pedido. Descriptores: son los restantes campos que describen las entidades de empresa. Por ejemplo, en la entidad empresa empleado, algunos de sus campos descriptores podrían ser NOMBRE DEL EMPLEADO, FECHA DE VINCULACIÓN, SUELDO. Las claves primarias y secundarias son descriptores • •

REGISTRO: Un registro es el conjunto completo de datos relacionados pertenecientes a una entrada. BASES DE DATOS: Una base de datos es una colección integrada de datos almacenados en distintos tipos de registros, de forma que sean accesibles para múltiples aplicaciones.

La interrelación de los registros se obtiene de las relaciones entre los datos, no de su lugar de almacenamiento físico. Los registros para distintas entidades se almacenan comúnmente en una base de datos (mientras que los archivos almacenan registros para una única entidad). Por ejemplo, en una base de datos de una universidad, se interrelacionan los registros de los estudiantes, cursos y profesores en la misma base de datos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

138

Las bases de datos no eliminan la necesidad de archivos en un sistema de información. Los distintos tipos de archivos siguen siendo necesarios para capturar los detalles de los eventos y actividades de la empresa, para preparar reportes o almacenar datos que no están en la base de datos. El uso de los diagramas de estructuras de datos requiere que el analista haga preguntas importantes acerca de la entidad a describir: • • •

¿Cuáles son los campos que identificarán de manera única una ocurrencia de la entidad? ¿Por qué medios se accesa la información acerca de la entidad? ¿Cuáles otros datos describen los atributos de la entidad?

Ejemplo: Diseño de un diagrama de entidad relación para la base de datos pedidos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

139

3.1. Diseño de especificaciones para programas: (Diseñar los programas de aplicación): Las especificaciones para programas son por sí mismas un diseño. Ellas describen cómo transformar las especificaciones de diseño del sistema (Salidas, entradas, archivos, procesamiento y otras) en software de computadora. El diseño de software de computadora es importante asegurarse que: •

Los programas producidos lleven a cabo todas las tareas y lo hagan en la forma establecida.

•

La estructuración del software en módulos permita su prueba y validación para determinar si los procedimientos son correctos.

•

Las modificaciones futuras se puedan realizar en forma eficiente y con un mínimo de interrupción en el diseño del sistema.

Un sistema será diseñado sólo una vez, pero será usado repetidamente y es muy probable que evolucione en la medida que cambien las necesidades de los usuarios. Estas observaciones añaden más importancia al diseño de software. Muchos sistemas de información, ya sea implantado en sistemas de cómputo grande o pequeño, interactúan con las bases de datos que abarcan varias aplicaciones. Dada la importancia que tienen las bases de datos en muchos sistemas, su diseño es establecido y vigilado por un experto en el diseño de sistemas que tiene la responsabilidad de desarrollar y mantener la base de datos, usualmente llamado administrador de base de datos o DBO. El analista proporciona: • •

Los datos que son necesarios de la base de datos. Las acciones que tendrán efecto sobre la propia base (por ejemplo, la recuperación de datos, cambios en los valores de los datos o el ingreso de nuevos datos en la base).

En algunas organizaciones existe una separación entre las responsabilidades del programador y las que tienen los analistas. En otras, tanto los programadores como analistas comparten las responsabilidades.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

140

3.2. Diseño de procedimientos: (Diseñar el sistema de procesamiento de datos) Los procedimientos especifican qué tareas deben efectuarse al utilizar un sistema y quiénes son los responsables de llevarlos a cabo. Entre los procedimientos importantes se encuentran: •

Procedimientos para entrada de datos. Métodos para la captura de datos de las transacciones y su ingreso en el sistema de información.

•

Procedimientos durante la ejecución. Pasos y acciones emprendidos por los operadores del sistema y, en ciertos casos, por los usuarios finales que interactúan con el sistema para alcanzar los resultados deseados.

•

Procedimientos para el manejo de errores. Acciones a seguir cuando se presentan resultados inesperados.

•

Procedimientos de seguridad y respaldo. Acciones para proteger al sistema y sus recursos contra posibles daños.

Ejemplo: procedimiento para la captura de datos de clientes (desarrollado en Visual Basic 2008)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

141

3.3. Diseño de controles Los analistas de software también deben anticipar los errores que se cometerán al ingresar los datos en el sistema o al solicitar la ejecución de ciertas funciones. Algunos errores no tienen importancia ni consecuencias, pero otros pueden ser tan serios que ocasionarían la eliminación de datos o el uso inapropiado del sistema. Un buen diseño de sistema de información ofrecerá los medios para detectar y manejar el error, los controles proporcionan medios para: • • • •

Asegurar que solo los usuarios autorizados tengan acceso al sistema Garantizar que las transacciones son aceptables Validar los datos para comprobar su exactitud Determinar si se han omitido datos que son necesarios.

3.4. Diseño de interfaz de usuario (IU) La interfaz de usuario es el mecanismo a través del cual se establece un dialogo entre el programa y el usuario. La Interfaz de Usuario, es un conjunto de elementos hardware y software de una computadora que presentan información al usuario y le permiten interactuar con la información y con la computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software. Existen tres puntos de vista distintos en una IU que son: • • •

El del usuario, El del programador El del diseñador.

Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a través de su experiencia. El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones adecuadas para modificar el mismo. Los modelos subyacen en la interacción con las computadoras, de ahí su importancia.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

142

Gráfico basado en el texto, Ingeniería del Software de Roger S. Pressman

3.5. Modelo del usuario El usuario tiene su visión personal del sistema, y espera que éste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudiándolo, ya sea realizando tests de usabilidad, entrevistas, o a través de una realimentación. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo.

3.6. Modelo del diseñador: El diseñador mezcla las necesidades, ideas, deseos del usuario y los materiales de que dispone el programador para diseñar un producto de software. Es un intermediario entre ambos. El modelo del diseñador describe los objetos que utilizan los usuarios, su presentación al mismo y las técnicas de interacción para su manipulación. Consta de tres partes: presentación, interacción y relaciones entre los objetos. Presentación, es lo primero que acapara la atención del usuario, pero más tarde pasa a un segundo plano, y adquiere más importancia la interacción con el producto para poder satisfacer sus expectativas. La presentación no es lo más relevante y un abuso en la misma

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

143

(por ejemplo, en el color o la sobre dimensión de controles en una pantalla) puede ser contraproducente, distrayendo al usuario. La segunda parte del modelo define las técnicas de interacción del usuario, a través de diversos dispositivos. Relaciones entre los objetos, es la más importante, y es donde el diseñador determina el uso de una expresión adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia arriba. Una vez definida la metáfora y los objetos del interfaz, los aspectos visuales saldrán de una manera lógica y fácil.

3.7. Modelo del ingeniero de software: Es el más fácil de visualizar, al poderse especificar formalmente. Está constituido por los objetos que manipula el programador, distintos de los que trata el usuario (ejemplo: el programador llama base de datos a lo que el usuario podría llamar agenda). Estos objetos deben esconderse del usuario. Los conocimientos del programador incluyen la plataforma de desarrollo, el sistema operativo, las herramientas de desarrollo y especificaciones. Sin embargo, esto no significa necesariamente que tenga la habilidad de proporcionar al usuario los modelos y expresiones más adecuadas. Reglas para el diseño de interfaz de usuario Existen directrices importantes para el diseño e implementación de IU, ya sea para las IU gráficas, como para la Web. Anticipación, las aplicaciones deberían intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la información, recopilarla o invocar las herramientas que va a utilizar. Autonomía, la computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender rápidamente a usar la aplicación.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

144

Percepción del Color, aunque se utilicen convenciones de color en la IU, se deberían usar otros mecanismos secundarios para proveer la información a aquellos usuarios con problemas en la visualización de colores. Valores por Defecto, No se debe utilizar la palabra "Defecto" en una aplicación o servicio. Puede ser reemplazada por "Estándar" o "Definida por el Usuario", "Restaurar Valores Iníciales" o algún otro término especifico que describa lo que está sucediendo. Eficiencia del Usuario, Se debe considerar la productividad del usuario antes que la productividad de la máquina. Si el usuario debe esperar la respuesta del sistema por un período prolongado, estas pérdidas de tiempo se pueden convertir en pérdidas económicas para la organización. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los problemas. Los menús y etiquetas de botones deben tener las palabras claves del proceso.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

145

3.8. Interfaces Explorables Siempre que sea posible se debe permitir que el usuario pueda salir ágilmente de la IU, dejando una marca del estado de avance de su trabajo, para que pueda continuarlo en otra oportunidad. Para aquellos usuarios que sean nuevos en el uso de la aplicación, se deberá proveer de guías para realizar tareas que no sean habituales. Es conveniente que el usuario pueda incorporar elementos visuales estables que permitan, no solamente un desplazamiento rápido a ciertos puntos del trabajo que esté realizando, sino también un punto de partida. La IU debe poder realizar la inversa de cualquier acción que pueda llegar a ser de riesgo, de esta forma se apoya al usuario a explorar el sistema sin temores. Siempre se debe contar con un comando "Deshacer". Este suprimirá la necesidad de tener que contar con diálogos de confirmación para cada acción que realice en sistema. El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por ello que la IU debe tener un objeto fácil de accionar con el cual poder finalizar la aplicación.

3.9. Método Hipo El método HIPO es usado con frecuencia para desarrollar software de sistemas. HIPO es una abreviatura del nombre en inglés de la entrada-proceso-salida-jerárquica, este método fue desarrollado por IBM para sus sistemas operativos grandes y complejos.

Propósito La suposición en la que HIPO se basa es que es fácil perder la pista de la función propia de un sistema o componente de un sistema grande. Esta es una razón por la que es difícil comparar los sistemas existentes contra sus especificaciones originales (y por lo tanto, porque pueden ocurrir fallas incluso en los sistemas técnicamente bien formulados). Desde el punto de vista del usuario, una sola función puede a menudo extenderse a varios módulos, por lo tanto, el interés del analista es entender, describir y documentar los módulos y su interacción de forma que se obtenga el detalle suficiente, pero que no se pierda de vista el panorama general. Los diagramas HIPO son descripciones gráficas del sistema, en vez de prosa o narrativa. Ayudan a los analistas a responder tres preguntas guía:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

146

1. ¿Qué hace el sistema o módulo (Se pregunta cuando se diseña el sistema). 2. ¿Cómo lo hace? (se pregunta cuando se revisa el código de prueba o mantenimiento) 3. ¿Cuáles son las entradas y las salidas? (se pregunta cuando se revisa el código de prueba o mantenimiento) Una descripción de la técnica HIPO para un sistema consta de una tabla visual de contenidos y los diagramas funcionales. Tabla visual de contenidos La tabla visual de contenidos (VTOC) muestra la relación entre cada uno de los documentos que conforman un paquete HIPO. Este consiste en un diagrama de jerarquía que identifica los módulos en un sistema mediante un número y en relación con los otros y da una descripción breve de cada módulo. Los números en la sección de contenidos corresponden a aquellos en la sección de organización. Los módulos se organizan crecientemente, dependiendo de la complejidad del sistema, es normal tener tres o cinco niveles de módulos. Diagramas funcionales Existe un diagrama para cada caja de la tabla visual de contenidos (VTOC). Cada diagrama muestra la entrada y la salida, los procesos principales, movimientos de datos y los puntos de control. Los símbolos de los diagramas de flujo tradicionales representan los medios, tales como cinta magnética, disco magnético y salida impresa. Los diagramas de HIPO son efectivos para documentar un sistema. También ayuda a los diseñadores y los fuerza a pensar cómo cumplir con las especificaciones y dónde hay que ligar las actividades y componentes. Sin embargo, se basan en un conjunto de símbolos especializados que requieren de explicación, una preocupación adicional si se compara con la simplicidad de, por ejemplo, los diagramas de flujo de datos. Los diagramas Hipo tienen su mayor fuerza en la documentación del sistema.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

147

Gráfico basado en el texto, Análisis y Diseño de Sistemas de Información de James A. Senn

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

148

4. Diseño Orientado A Objetos Es una fase de la metodología orientada a objetos para el desarrollo de Software. Su uso induce a los ingenieros de software a pensar en términos de objetos, en vez de procedimientos, cuando planifican su código. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La “interfaz del objeto”, es la forma de interactuar con el objeto, también es definida en esta etapa. Un programa orientado a objetos es descrito por la interacción de esos objetos. El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el análisis de requisitos. El diseño de software se realiza a tres capas o niveles: • • •

Conceptual Lógico Físico

Ejemplo Representación grafica de la arquitectura lógica de tres capas de una aplicación cliente – servidor

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

149

4.1. Diseño Conceptual El diseño conceptual es considerado como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño conceptual es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas:

1. 2. 3. 4. 5. 6.

Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa

Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quién, qué, cuándo, dónde y por qué de la solución.

4.2. Diseño Lógico El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. Un objeto de negocios es la encapsulación de un servicio que abstrae las cualidades esenciales de algo de interés. Un servicio es una unidad con capacidad de cómputo. Un servicio debe satisfacer lo siguiente: • • • •

Ser seguro, lo que equivale a un uso correcto y con autorización Ser válido, qué tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente Contar con un catálogo de servicios que constituye un repositorio de servicios.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

150

Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los módulos operen como unidades completas de trabajo. Las tareas de verificación incluyen: • • • • •

Una verificación independiente: Pre y post condiciones Lógica y funcionalidad individual Una verificación dependiente: Verificación de dependencias Que operan como una unidad específica de trabajo

El diseño lógico comprende las siguientes tareas: • • • • • •

Identificar y definir los objetos de negocio y sus servicios Definir las interfaces Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario

Para definir los objetos de negocios y sus servicios se puede usar la técnica de análisis nombre-verbo de los escenarios de uso. También se puede emplear la técnica sujeto-verboobjeto directo. En estas técnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Una interface tiene las siguientes partes: • • • • •

Nombre Precondiciones, lo que debe estar presente antes de ejecutarse Postcondiciones, estado final Capacidad o funcionalidad (SQL, pseudocódigo, función matemática) Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realización de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente: • • • • • • •

Identificar los eventos disparadores (triggers) Determinar cualquier dependencia (existencial o funcional) Determinar cualquier problema de consistencia o secuencia Identificar cualquier regulación de tiempo crítico Considerar algún problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a través de la ubicación

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

151

•

Determinar cuando el servicio que controla la transacción es dependiente de los servicios contenidos en otros objetos de negocio

La validación del modelo lógico debe ser tal que éste sea: • • •

Completo: debe representar todos los escenarios de uso, Correcto: el comportamiento lógico debe corresponder con el comportamiento conceptual, y Claro: los objetos de negocio y servicios no deben ser ambiguos

En el diseño lógico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología cambiando únicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario controlan la interacción. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinación de éstos. Generalmente involucra una interfaz gráfica de usuario (GUI) o puede ser no visual (mensajes o funciones), maneja todos los aspectos de la interacción con la aplicación. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. Un servicio de usuario incluye un contenido (qué se necesita comunicar al usuario) y una forma (cómo se comunica el contenido) cuando es necesaria la comunicación. Los servicios de negocio convierten datos recibidos de los servicios de datos y de usuario en información (datos más regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Las tareas de los servicios de negocio son: • • • •

Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en información Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transacción.

Los servicios de datos son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categorías como las siguientes: 1. Declaración del esquema y su evolución (estructuras de datos, tipos, acceso indexado, SQL, APIs ) 2. Respaldo y recuperación (recuperación de datos si un evento falla) 3. Búsqueda y Lectura (búsquedas, compilación, optimización y ejecución de solicitudes, formación de un conjunto de resultados) 4. Inserción, actualización y borrado (procesar modificaciones consistentemente transaccional). Una transacción es atómica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o después) y durable (una vez completada, ésta sobrevive). 5. Bloqueo (permite al acceso concurrente a los datos)

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

152

6. Validación de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores) 7. Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios) 8. Administración de la conexión (mecanismos básicos para establecer una sesión de los servicios de datos). Establecer una conexión involucra: una identificación, la colocación y provisión de datos, tiempo de sesión, el tipo de interacción (conversacional, transaccional, multiusuario, mono usuario). 9. Distribución de datos (Distribuye información, a múltiples unidades de recuperación, bases de datos heterogéneas, según la topologías de la red).

4.3. Diseño físico El diseño físico traduce el diseño lógico en una solución que se puede implementar a un costo económico. El componente es la unidad de construcción elemental del diseño físico. Las características de un componente son: • • • • •

Se define según cómo interactúa con otros Encapsula sus funciones y sus datos Es reusable a través de las aplicaciones Puede verse como una caja negra Puede contener otros componentes

En el diseño físico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico) y la agregación y contención (un componente puede rehusar utilizando técnicas de agregación y contención, sin duplicar código). El diseño físico debe involucrar: • • •

El diseño para distribución, debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red. El diseño para multitarea, debe diseñarse en términos de la administración concurrente de dos o más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso) El diseño para uso concurrente, el desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud.

El diseño con el manejo de errores y prueba de eventos: • •

Validando los parámetros, a la entrada antes de continuar con cualquier proceso. Protegiendo recursos críticos, manejar excepciones para evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

153

• • •

Protegiendo datos importantes, contar con una excepción a la mitad de la actuación en las bases de datos. Debugging, crear una versión para limpiar errores. Protección integral de transacciones de negocios, los errores deben regresarse al componente que llama.

El diseño físico comprende las siguientes tareas: • • • • • • •

Definir los componentes Refinar el empaquetamiento y distribución de componentes Especificar las interfaz de los componentes Distribuir los componentes en la red Distribuir los repositorios físicos de datos Examinar la tolerancia a fallas y la recuperación de errores Validar el diseño físico

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

154

De las tareas anteriores la más importante es la distribución de los datos que pueden ser centralizados, una partición, un extracto o una réplica. Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos. Una partición de datos es una segmentación de la base de datos maestra. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobre posición entre particiones. En una partición horizontal cada fila existe en una sola base de datos. En una partición vertical cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porción de la base de datos maestra. No se permite la actualización. Se usa un timestamp o etiqueta de tiempo para indicar qué tan viejos son los datos. Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local. No se permiten actualizaciones en la base de datos réplica y en la base de datos maestra a la vez, por lo que debe haber sincronización entre ambas.

4.4. CONCEPTOS OBJETOS

DEL

DISEÑO

ORIENTADO

El diseño orientado a objeto introduce un nuevo conjunto de términos, notaciones y procedimientos para la derivación del diseño de software. En esta sección repasamos la terminología orientada a objetos introducida en la unidad 3. Objeto, Operaciones y Mensajes Objeto: conjuntos modulares de elementos de información del mundo real (denominado un dominio). Un objeto es una representación detallada, concreta y particular en el contexto de la programación orientada a objetos. Tal representación determina su identidad, su estado y su comportamiento particular en un momento dado. Un objeto se caracteriza por: • •

Atributos, datos que caracterizan al objeto, son variables que almacenan datos relacionados al estado de un objeto. Métodos (usualmente llamados funciones de miembro): los métodos de un objeto caracterizan su comportamiento, es decir, son todas las acciones denominadas operaciones que el objeto puede realizar por sí mismo. Estas operaciones hacen posible que el objeto responda a las solicitudes externas o que actué sobre otros objetos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

155

•

Identidad: el objeto tiene una identidad, que distingue de otros objetos, sin considerar su estado. Por general, esta identidad se crea mediante un identificador que deriva naturalmente de un problema por ejemplo: un producto puede estar representado por un código, un automóvil, por un numero de modelo, etc.

Operaciones : definen el comportamiento de un objeto y cambian, de alguna manera, los atributos de dicho objeto. Más concretamente, una operación cambia valores de uno o más atributos contenidos en el objeto. Aunque existen muchos tipos diferentes de operaciones, estas pueden clasificarse en tres grandes categorías: • • •

Operaciones que manipulan, de alguna manera, datos. Operaciones que realizan algún cálculo. Operaciones que monitorizan un objeto frente a la ocurrencia de un suceso de control.

Mensajes: Los mensajes son el medio a través del cual los objetos interactúan. Un mensaje estimula la ocurrencia de ciertos comportamientos en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operación.

4.5. Clases y Objetos Clase: es la estructura de un objeto que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real. Por consiguiente, todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulación de los atributos.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

156

Atributos: Son los que están asociados a clases y objetos, y que ellos describen la clase o el objeto de alguna manera. Un atributo puede tomar un valor definido por un dominio enumerado. Un dominio es simplemente un conjunto de valores específicos. Operaciones, Métodos Y Servicios: Un objeto encapsula datos y los algoritmos que procesan estos datos. Estos algoritmos son llamados Operaciones, métodos o servicios y pueden ser vistos como módulos en un sentido convencional. Cada una de las operaciones encapsuladas por un objeto proporciona una representación de uno de los comportamientos del objeto. Un clase que esta realidad, términos

es la estructura de un objeto, es decir, es la definición de todos los elementos de hecho un objeto. En este orden de idea un objeto es, el resultado de una clase. En un objeto es una instancia de una clase, por lo que se puede intercambiar los objeto o instancia.

Instancia: se produce con la creación de un objeto perteneciente a una clase (instanciar una clase), que hereda entonces sus atributos, propiedades y métodos para ser usados dentro de un programa, ya sea como contenedores de datos o como partes funcionales del programa al contener en su interior funcionalidades de tratamiento de datos y procesamiento de la información que ha sido programada previamente en la clase a la que pertenece. Diagramas de clases

El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones. En el mundo real puede ser Mecanismos de abstracción:

visto

desde

abstracciones

diferentes

(subjetividad)

1. Clasificación / Instanciación Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

157

2. Composición / Descomposición 3. Agrupación / Individualización 4. Especialización / Generalización La clasificación es uno de los mecanismos de abstracción más utilizados. La clase define el ámbito de definición de un conjunto de objetos, y cada objeto pertenece a una clase, los objetos se crean por instanciación de las clases. Cada clase se representa en un rectángulo con tres compartimientos: • • •

nombre de la clase atributos de la clase operaciones de la clase

Los atributos de una clase no deben ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos, que son: • • •

(-) Privado: es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++) (#) Protegidos: los atributos/operaciones protegidos están visibles para las clases derivadas de la original. (+) Publicas: los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)

Relaciones entre clases: Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relación son: • •

Asociación y Agregación (vista como un caso particular de asociación) Generalización/Especialización.

Las relaciones de Agregación y Generalización forman jerarquías de clases.

4.6. Asociación: La asociación expresa una conexión bidireccional entre objetos. Una asociación es una abstracción de la relación existente en los enlaces entre los objetos. Puede determinarse por la especificación de multiplicidad (mínima...máxima) • • • • •

Uno y sólo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) * Cero o muchos 0..* Cero o muchos

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

158

•

1..* Uno o muchos (al menos uno)

4.7. Agregación La agregación representa una relación parte de entre objetos. En UML se proporciona una escasa caracterización de la agregación. Esta relación puede ser caracterizada con precisión determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes. Una agregación se podría caracterizar según: ¿Puede el objeto-parte comunicarse directamente con objetos externos al objeto agregado? No => inclusiva Si => no inclusiva ¿Puede cambiar La composición del objeto agregado? Si => dinámica No => estática Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una parte del dominio. Un Diagrama de Objetos representa una situación concreta del dominio. Las clases abstractas no son instanciadas.

También se usan los términos “métodos” y “servicios” Procedimientos estándar del sistema operativo Windows Es un evento que se ejecuta cuando se cumple una condición establecida al realizar una operación de inserción (INSERT) actualización (UPDATE) o borrado (DELETE) Es un dispositivo que permite interconectar redes con protocolos y arquitecturas diferentes a todos los niveles de comunicación.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

159

5. Encapsulamiento, Herencia y Polimorfismo El encapsulamiento: significa que toda la información de un objeto se encuentra empaquetada bajo un nombre y puede reutilizase como una especificación o componente de un programa. Las clases OO y los objetos derivados de ella encapsulan los datos y las operaciones que trabajan sobre estos en un único paquete. Estos proporcionan importantes beneficios: • •

Detalles de implementación interna de datos Procedimientos ocultos al mundo exterior

Las Estructuras de datos y las operaciones que las manipulan están mezcladas en una entidad sencilla: La clase. Ejemplo: encapsulación de la clase cliente en Visual Basic 2008

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

160

Las Interfaces entre objetos encapsulados están simplificadas. La Herencia: es una de las diferencias clave entre sistemas convencionales y sistemas OO. La reutilización se realiza directamente. Cualquier cambio en los datos u operaciones contenidas dentro de una superclase se hereda inmediatamente por todas las subclases que se derivan de la superclase. La herencia funciona de la siguiente forma: Una Subclase hereda todos los Atributos y operaciones asociadas con su superclase. El polimorfismo: Capacidad que tienen los objetos de una clase de responder al mismo mensaje o evento en función de los parámetros utilizados durante su invocación.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

161

El polimorfismo permite que un número de operaciones diferentes tengan el mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno más independiente. El Polimorfismo es una característica que reduce en gran medida el esfuerzo necesario para extender un sistema OO. Para entender el polimorfismo, considere una aplicación convencional que debe abrir cuatro tipos diferentes de objetos: Puerta, Caja, Candado y Libro.

Ahora se presenta un ejemplo de herencia

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

162

El siguiente es la implementación de la clase cliente en código fuente Visual Basic 2008.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

163

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

164

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

165

Nota: este es un segmento de código para la conexión a una base de datos diseñada en SQL-SERVER 2005, con fines exclusivamente académico.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

166

Tecnol贸gico de Antioquia Instituci贸n Universitaria Vicerrector铆a Acad茅mica

167

6. Diseño Web Para asegurar que un sitio cumple con los niveles de usabilidad requeridos, es importante que el diseñador haga uso de una metodología, de técnicas y procedimientos ideados para tal fin. El Diseño Web se caracteriza por asumir que todo el proceso de diseño y desarrollo del sitio web debe estar conducido por el usuario, sus necesidades, características y objetivos. Centrar el diseño en sus usuarios, implica involucrar desde el comienzo a los usuarios en el proceso de desarrollo del sitio; conocer cómo son, qué necesitan, para qué usan el sitio; probar el sitio con los propios usuarios; investigar cómo reaccionan ante el diseño, cómo es su experiencia de uso; e innovar siempre con el objetivo claro de mejorar la experiencia del usuario. El proceso de Diseño Web se divide en varias fases o etapas, algunas de las cuales tienen carácter iterativo. Como aproximación se muestra el siguiente diagrama:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

168

Como indica el diagrama, las fases de "diseño", "prototipo" y "evaluación" son cíclicos e iterativos. Esto quiere decir que todo lo que se diseñe debe ser constantemente evaluado a través de su prototipo, para así poder corregir errores de usabilidad desde los primeros momentos del desarrollo. Evaluar el sitio web únicamente una vez finalizado su desarrollo haría mucho más costosa la reparación de errores de usabilidad, ya que siempre es más económico reconducir un diseño que rediseñar completamente el sitio.

6.1. Planificación Todo proyecto debe comenzar por una correcta planificación. En esta etapa se identifican los objetivos del sitio, así como las necesidades, requerimientos y objetivos de la audiencia potencial. Confrontando esta información se definen los requerimientos del sitio web, entre los que se pueden contar requerimientos técnicos (back-end y front-end ), recursos humanos y perfiles profesionales necesarios, y adecuación del presupuesto disponible. Nota: La separación del sistema en "front ends" y "back ends" es un tipo de abstracción que ayuda a mantener las diferentes partes del sistema separadas. La idea general es que el front-end sea el responsable de recolectar los datos de entrada del usuario, que pueden ser de muchas y variadas formas, y procesarlas de una manera conforme a la especificación que el back-end pueda usar. La conexión del front-end y el back-end es un tipo de interfaz. Se trata, pues, de establecer un equilibrio entre lo que puede ofertar el proveedor y lo que necesita el usuario. El sitio web, sus contenidos y diseño, debe cumplir precisamente este cometido: servir de medio para la consecución de objetivos por parte de proveedor y usuario. El diseñador debe obtener información precisa tanto de las necesidades y objetivos del proveedor como del usuario. En el primer caso, mediante entrevistas y reuniones con los responsables del sitio, será relativamente fácil obtener dicha información. Más dificultoso, pero al mismo tiempo más importante, es obtener esta información del usuario: ¿Qué necesita?, ¿Cuáles son sus objetivos?, ¿Cómo se comporta y actúa?, ¿Cuál será el contexto de uso? y ¿Cómo afectará a la interacción, experiencia y conocimientos previos?. La respuesta a estas preguntas se resuelve estudiando a la audiencia a través de métodos de indagación. Éstos engloban métodos de aproximación contextual, estudios de campo, métodos de aproximación por grupos y métodos de aproximación individual (encuestas, cuestionarios y entrevistas). Cuanto más conozcamos a la audiencia, más adaptado será el diseño y más satisfactoria la experiencia del usuario final. Como se puede ver, la etapa de planificación se basa casi completamente en la recogida, análisis y ordenación de toda la información posible, con el objetivo de tener una base sólida sobre la que se puede tomar decisiones de diseño en las siguientes etapas del proceso.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

169

6.2. Diseño La etapa de Diseño es el momento del proceso de desarrollo para la toma de decisiones acerca de cómo diseñar o rediseñar, en base al conocimiento obtenido en la etapa de planificación, así como a los problemas de usabilidad descubiertos en etapas de prototipo y evaluación.

6.3. Modelado del usuario Toda la información obtenida de los estudios de usuarios realizados en la anterior fase de planificación debe servir como base para comenzar el diseño, pero para ello se debe resumir y sintetizar dicha información. Este paso se denomina modelado del usuario y consiste en la definición de clases o perfiles de usuarios en base a atributos comunes. Los atributos sobre los que se hará la clasificación dependen de la información que se tenga de la audiencia, pero normalmente se tratarán de atributos tales como necesidades de información, condiciones de acceso, experiencia y conocimientos. Mediante esta técnica, el diseñador tendrá en mente para quién diseña, qué espera encontrar el usuario y en qué forma. El diseño del sitio web debe estar orientado al usuario, organizando y estructurando la información según los modelos definidos de usuarios. El problema de esta técnica de modelado de usuario es que cuando la audiencia es demasiado extensa y heterogénea, la categorización total de la audiencia puede no ser viable. En estos casos es conveniente hacer uso del enfoque 'persona', ideado por Cooper. Esta técnica de modelado del usuario se basa en la definición de arquetipos de usuarios que representan patrones de conducta, objetivos y necesidades. Estos arquetipos, llamados "personas", son descripciones en forma narrativa de usuarios, a los que se les da una identidad inventada: fotografía, nombre,... En cambio, todos los atributos, características y necesidades del arquetipo deben estar basados en información real extraída de la audiencia objetiva del sitio web, ya que si éstos fueran datos inventados la técnica perdería toda su utilidad. Además se deben definir "escenarios" - descripciones de situaciones de uso del sitio - sobre los que se puede contextualizar la interacción persona-aplicación web. Las "personas" definidas, al contrario de lo que se pretendía con la categorización de la audiencia, no pueden representar al total de los usuarios del sitio web, pero es que ésta no es su misión. La función de esta técnica es la de servir de soporte para la toma de decisiones en el diseño del sitio, permitiendo al desarrollador realizar un diseño centrado en el usuario, o más correctamente, en "algún" usuario. Este usuario podemos considerarlo 'real', ya que aunque

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

170

no pertenece al mundo real, su descripción está basada sobre un nutrido grupo de usuarios reales. Es común que el diseñador se imagine a sí mismo usando el sitio y por tanto sea incapaz de comprender por qué a alguien le puede resultar difícil, incomodo y hasta frustrante su uso. Estos arquetipos de usuarios conseguirán precisamente que el diseñador tenga en mente a un usuario 'real', con limitaciones, habilidades y necesidades reales.

6.4. Diseño conceptual El objetivo de la fase de Diseño Conceptual es definir el esquema de organización, funcionamiento y navegación del sitio. No se especifica qué apariencia va a tener el sitio, sino que se centra en el concepto mismo del sitio: su arquitectura de información. Los sitios web son sistemas hipermedia formados por conjuntos de páginas interrelacionadas por enlaces unidireccionales, pudiendo cada una de estas páginas contener sub-elementos con entidad propia, contenidos multimedia y herramientas interactivas. La "estructura" del sitio web se refiere precisamente a las conexiones y relaciones entre páginas, a la topología de la red de páginas, así como a la distribución de los elementos de información contenidos en las páginas; y la "navegación" a las posibilidades y forma en que cada página presenta las opciones de desplazamiento hacia otras páginas. La definición de la estructura del sitio puede hacerse desde dos enfoques diferentes y complementarios: • •

Descendente, se trata de estructurar del "todo" a las "partes", dividir los contenidos en páginas y definir los enlaces entre páginas. Ascendente, por el contrario, se definen los bloques mínimos de información, estructuración que va más allá de la propia segmentación de información en páginas.

Una vez definida la estructuración del sitio es necesario documentarla, para así tener un modelo de referencia sobre el que se sustentara el desarrollo del sitio. La forma de documentar arquitecturas se suele hacer a través de grafos y esquemas, con el objetivo de que sean de fácil y rápida comprensión por todos los miembros del equipo de desarrollo. Si la arquitectura es ascendente normalmente se documentará a través de diagramas entidad-relación. Por otro lado, cuando la arquitectura a documentar es la descendente, para sitios web se propone el uso del vocabulario gráfico de Garret. A través de unas sencillas convenciones gráficas para la diagramación de la arquitectura, se puede definir la estructura de la información así como la navegación del sitio. Otras tareas a llevar a cabo por el Arquitecto de Información o diseñador en la fase de Diseño Conceptual son:

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

171

Definir sistemas de clasificación para los contenidos; Elaborar índices y mapas del sitio; Aplicar metadatos a cada una de las páginas y sub-elementos de información; y Definir el Sistema de Rotulado.

6.5. Diseño visual y definición del estilo En esta fase se especifica el aspecto visual del sitio web: • • •

Composición de cada tipo de página. Aspecto y comportamiento de los elementos de interacción. Presentación de elementos multimedia.

Con el objetivo de evitar la sobrecara informativa, en el diseño de cada interfaz se debe tener en cuenta el comportamiento del usuario en el barrido visual de la página, distribuyendo los elementos de información y navegación según su importancia en zonas de mayor o menor jerarquía visual, por ejemplo, las zonas superiores del interfaz poseen más jerarquía visual que las inferiores. Además de la posición de cada elemento en la interfaz, existen otras técnicas para jerarquizar información como son: • • • • •

Uso del tamaño y espacio ocupado por cada elemento para otorgarle importancia en la jerarquía visual. Utilización del contraste de color para discriminar y distribuir información. Uso de efectos tipográficos para enfatizar contenidos. Rotura de la simetría y uso de efectos de relieve, Profundidad para resaltar elementos, etc.

Además de evitar la sobrecarga informativa jerarquizando los contenidos mediante las técnicas descritas, para evitar la sobrecarga memorística se recomienda definir menús de navegación con un número de opciones reducido, normalmente no más de nueve diferentes. Otro aspecto importante en el diseño visual del sitio es la accesibilidad. En el uso de colores, por ejemplo, se debe ofrecer suficiente contraste entre texto y fondo para no dificultar la lectura, e igualmente seleccionar combinaciones de colores teniendo siempre en cuenta las discapacidades visuales en la percepción del color que pudieran presentar los usuarios. Al utilizar imágenes en el diseño, por motivos de accesibilidad y comprensibilidad, se debe cuidar su resolución y tamaño, así como en fotografías la no pérdida de significación o contexto por recorte o minimización excesiva de la imagen. Desde una perspectiva más amplia del diseño visual del sitio es importante mantener una coherencia y estilo común entre todas las páginas, proporcionando una consistencia visual a todo el sitio. Para asegurar que esta coherencia se cumple, es útil elaborar un documento o guía de estilo que sirva de documento referencia para todo el equipo de desarrollo.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

172

6.6. Diseño de contenidos En el diseño de contenidos hipermedia se debe mantener un equilibrio entre lo que serían contenidos que no aprovechasen las nuevas posibilidades hipertexto y multimedia, y lo que serían contenidos caóticos o desorientados debido a un uso excesivo y no pausado de las posibilidades hipermedia. Sin prescindir de las capacidades que ofrece el nuevo medio, de lo que se trata es de diseñar contenidos interrelacionados y vinculados, manteniendo cierta coherencia informativa, comunicacional y organizativa. La escritura de hipertexto se debe realizar de forma diferente a la tradicional. El nuevo medio y sus características obligan a ser concisos, precisos, creativos y estructurados a la hora de redactar. Debemos conocer a quién nos dirigimos y adaptar el lenguaje, tono y vocabulario utilizado al usuario objetivo. Algunas pautas a seguir en el diseño y redacción de contenidos son:

• • • • • • •

Seguir una estructura piramidal: La parte más importante del mensaje, el núcleo, debe ir al principio. Permitir una fácil exploración del contenido: El lector en entornos Web, antes de empezar a leer, suele explorar visualmente el contenido para comprobar si le interesa. Un párrafo = una idea: Cada párrafo es un objeto informativo. Se deben trasmitir ideas, mensajes... evitando párrafos vacíos o varios mensajes en un mismo párrafo. Ser conciso y preciso: Al lector no le gusta leer en pantalla. Vocabulario y lenguaje: Se debe utilizar el mismo lenguaje del usuario, no el de la empresa o institución. El vocabulario debe ser sencillo y fácilmente comprensible. Tono: Cuanto más familiar y cercano (sin llegar a ser irrespetuoso) sea el tono empleado, más fácil será que el lector preste atención. Confianza: La mejor forma de ganarse la confianza del lector es permitiéndole el diálogo, así como conocer cuanta más información posible acerca del autor.

6.7. Prototipado La evaluación de la usabilidad del sitio web se debe realizar desde las primeras etapas de diseño, pero ¿cómo evaluar un sitio web que no está implementado? A través de prototipos. La etapa de prototipado se basa en la elaboración de modelos o prototipos de la interfaz del sitio. Su aspecto no se corresponde exactamente con el que tendrá el sitio una vez

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

173

finalizado, pero pueden servir para evaluar la usabilidad del sitio sin necesidad de esperar a su implementación. Podemos clasificar los tipos de prototipado según el nivel de funcionalidad reproducida: •

Prototipado horizontal: Se reproduce gran parte del aspecto visual del sitio, pero sin que esos modelos de interfaz estén respaldados por la funcionalidad real que tendrá finalmente el sitio.

•

Prototipado vertical: Se reproduce únicamente el aspecto visual de una parte del sitio, pero la parte reproducida poseerá la misma funcionalidad que el sitio web una vez implementado.

Según el grado de fidelidad o calidad del prototipo se distingue entre: •

Prototipado de alta fidelidad: El prototipo será muy parecido al sitio web una vez terminado.

•

Prototipado de baja fidelidad: El aspecto del prototipo distará bastante del que tenga el sitio web final.

En las primeras etapas de desarrollo del sitio web se puede hacer uso del prototipado en papel o de bajo costo, que consiste en reproducir los aspectos básicos de la interfaz del sitio en papel. Por ejemplo, podemos reproducir a través de bocetos cómo serán las diferentes páginas que conformarán el sitio a desarrollar, cada una en una página de papel diferente. La reproducción suele ser a mano (lápiz y tijeras), por lo que resulta una técnica de prototipado muy económica. Otra forma de realizar prototipos es mediante la reproducción del aspecto del sitio a través de herramientas software. Mediante el procesador de textos o un simple editor HTML podemos esbozar cómo será la interfaz del sitio. Hay que precisar que estos prototipos son reproducciones, no estados tempranos de implementación de la interfaz. Una vez que el prototipo se ha utilizado se tira, no es parte del sitio web. La utilidad real del prototipado se fundamenta en que no tendría sentido empezar a implementar una interfaz web si no nos hemos asegurado antes de que el diseño es usable.

6.8. Evaluación La evaluación de la usabilidad, la etapa más importante en el proceso de Diseño se puede realizar a través de varios métodos o técnicas y sobre diferentes representaciones del sitio (prototipos en papel, prototipos software, sitio web implementado).

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

174

Existe una gran diversidad de métodos para evaluación de usabilidad, aunque en la unidad 4 únicamente se describirán aquellos que creemos de más utilidad y aplicabilidad real en el contexto del desarrollo de aplicaciones web. Método por inspección: evaluación heurística Los métodos de inspección de la usabilidad de un sitio web son aquellos realizados por el experto en usabilidad, y que se basan en el recorrido y análisis del sitio identificando errores y problemas de diseño. La Evaluación Heurística es un tipo de método de inspección, que tiene como ventaja la facilidad y rapidez con la que se puede llevar a cabo. Este tipo de evaluación normalmente la lleva a cabo un grupo reducido de evaluadores que, en base a su experiencia, fundamentándose en reconocidos principios de usabilidad (heurísticos), y apoyándose en guías elaboradas para tal fin, evalúan de forma independiente el sitio web, contrastando finalmente los resultados con el resto de evaluadores. Diversos autores han propuesto diferentes conjuntos de heurísticos o principios de usabilidad a través de los cuales evalúan la usabilidad. Nielsen propone los siguientes: •

Visibilidad del estado del sistema: El sistema (o sitio web) siempre debe informar al usuario acerca de lo que está sucediendo. Por ejemplo, cuando en una interfaz tipo webmail se adjuntan ficheros a un mensaje, el sistema debe informar del hecho mostrando un mensaje de espera.

•

Lenguaje común entre sistema y usuario: El sistema debe hablar el lenguaje del usuario, huyendo de tecnicismos incomprensibles o mensajes crípticos.

•

Libertad y control por parte del usuario: El usuario debe tener el control del sistema, no se puede limitar su actuación. Se debe ofrecer siempre al usuario una forma de "salida de emergencia", como por ejemplo la representada por la opción para "saltar" animaciones de introducción (normalmente Flash).

•

Consistencia y estándares: La consistencia se refiere a, por ejemplo, no utilizar dos rótulos distintos para referirse a un mismo contenido, o no usar estilos diferentes dentro de un mismo sitio. Además el sitio web debe seguir estándares o convenciones de diseño ampliamente aceptados. Cuanto más se parezca un diseño y su funcionamiento al resto de sitios web, más familiar y fácil de usar resultará para el usuario.

•

Prevención de errores: Mejor que un buen mensaje de error es un diseño que prevenga que ocurra el error.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

175

Es mejor reconocer que recordar: Este principio hace mención a la visibilidad de las diferentes opciones, enlaces y objetos. El usuario no tiene por qué recordar dónde se encontraba cierta información, o cómo se llegaba a determinada página. •

Flexibilidad y eficiencia de uso: El sitio debe ser fácil de usar para usuarios novatos, pero también proporcionar atajos o aceleradores para usuarios avanzados.

•

Diseño minimalista: Cualquier tipo de información que no sea relevante para el usuario y que sobrecargue la interfaz debe ser eliminada.

•

Permitir al usuario solucionar el error: Por ejemplo, cuando un usuario introduce una consulta en un buscador y no obtiene ningún resultado, se debe informar al usuario sobre cómo solucionar el problema, por ejemplo con mensajes del tipo "introduzca algún sinónimo" o "quiso Usted decir...". Además no se debe borrar el contenido de la caja de búsqueda para que el usuario pueda rehacer la consulta.

•

Ayuda y Documentación: Siempre es mejor que un sitio web se pueda utilizar sin necesidad de ayuda o documentación, aunque en sitios web extensos o en procesos de interacción complejos (como el rellenado de un formulario), se debe proporcionar información de ayuda al usuario.

Hassan Montero y Martín Fernández proponen el siguiente modelo de evaluación heurística: •

Aspectos generales: Objetivos, coherencia y nivel de actualización de contenidos.

•

Identidad e Información: Identidad del sitio e información proporcionada sobre el proveedor y la autoría de los contenidos.

•

Lenguaje y redacción: Calidad de los contenidos textuales.

•

Rotulado: Significación y familiaridad del rotulado de los contenidos.

•

Estructura y Navegación: Idoneidad de la arquitectura de información y navegación del sitio.

•

Lay-out de la página: Distribución y aspecto de los elementos de navegación e información en la interfaz.

•

Búsqueda: Buscador interno del sitio.

•

Elementos multimedia: Grado de adecuación de los contenidos multimedia al medio web.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

176

•

Ayuda: Documentación y ayuda contextual ofrecida al usuario para la navegación.

•

Accesibilidad: Cumplimiento de directrices de accesibilidad.

•

Control y retroalimentación: Libertad del usuario en la navegación.

6.9. Método de ensayo con usuarios El ensayo con usuarios es una prueba de usabilidad que se basa en la observación y análisis de cómo un grupo de usuarios reales utiliza el sitio web, anotando los problemas de uso con los que se encuentran para poder solucionarlos posteriormente. Como toda evaluación de usabilidad, cuanto más esperamos para su realización, más costoso resultará la reparación de los errores de diseño descubiertos. Esto quiere decir que no sólo debemos realizar este tipo de pruebas sobre el sitio web una vez implementado, sino también, sobre los prototipos del sitio. Evaluación de usabilidad, es una prueba complementaria a la evaluación heurística, pero una prueba con usuarios es más costoso, por lo que es recomendable realizarlo siempre después de una evaluación heurística, ya que sería desperdiciar tiempo y dinero utilizarlo para descubrir errores de diseño motivados por el no cumplimiento en el desarrollo de principios generales de usabilidad (heurísticos). La ventaja que ofrecen las pruebas de usuarios frente a otro tipo de evaluaciones es que por un lado es una demostración con hechos, por lo que sus resultados son más fiables, y por otro porque posibilitan el descubrimiento de errores de diseño imposibles o difíciles de descubrir mediante la evaluación heurística. Llevar a cabo una prueba de usuarios formal obligaría a alquilar un local (laboratorio) adecuado, contratar a evaluadores especializados, así como delegar en alguna empresa la selección y reclutamiento de los participantes de la prueba. Realmente sería bastante costoso y poco viable para la gran mayoría de casos.

6.10. Implementación y lanzamiento En la implementación del sitio es recomendable utilizar estándares (HTML, XHTML...) para asegurar la futura compatibilidad y escalabilidad del sitio. Esto se debe a que, aunque puede ser tentador utilizar tecnologías propietarias, el panorama tecnológico puede hacerlas desaparecer o cambiar en poco tiempo. Igualmente es recomendable separar en la implementación contenido de estilo, mediante el uso de hojas de estilo (CSS) del lado del cliente y uso de bases de datos del lado del servidor. De esta forma se facilitará tanto el rediseño del sitio como la posibilidad de adaptación dinámica del diseño a las necesidades de acceso de cada tipo de usuario.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

177

En esta etapa del desarrollo se debe llevar, así mismo, un control de calidad de la implementación, supervisando que todo funcione y responda a cómo había sido planificado, ya que la usabilidad del sitio depende directamente de la funcionalidad. Si algo no funciona, sencillamente no se puede usar. Entre las técnicas para controlar la calidad de la implementación se pueden utilizar validadores automáticos de código como los proporcionados por el W3C ( http://www.w3c.org ), así como validadores para testar de forma semi-automática el cumplimiento de directrices de accesibilidad en el código, como el Test de Accesibilidad Web ( http://www.tawdis.net ). Una vez implementado el sitio y testada su funcionalidad se procede al lanzamiento del sitio, que consiste en su puesta a disposición para los usuarios. Se trata de un evento importante, muchas veces erróneamente apresurado debido a la necesidad de cumplir plazos de entrega. El primer encuentro entre usuario y el sitio web modelará en gran medida la percepción que el usuario tendrá del sitio en posteriores visitas. Por ello es necesario que durante los primeros meses a partir del lanzamiento, el sitio tenga un diseño y contenidos adaptados a este importante momento de su ciclo de vida. Es el momento de explicar a los usuarios el sitio, de enseñarles a usarlo, darles la bienvenida, "vendérselo"... Después de esos primeros meses de vida la audiencia del sitio habrá cambiado. Seguirá habiendo usuarios que accedan por primera vez al sitio, pero ya no representarán a la mayoría de la audiencia. A los usuarios habituales no se les puede seguir haciendo perder el tiempo dándoles la bienvenida o explicándoles qué es y en qué consiste el sitio web. Para asegurar que el sito llega a su audiencia potencial se hace uso de la promoción. La forma de llevar a cabo una campaña de publicidad o promoción dependerá de la naturaleza y características del sitio web. Se debe crear expectación, un conocimiento previo del sitio en los potenciales usuarios. Para ello es recomendable que antes del lanzamiento, desde la misma URL que tendrá finalmente el sitio, se ofrezca una página web explicativa de lo que será el sitio, cuándo estará disponible, así como información de contacto. Una vez realizado el lanzamiento se deben utilizar técnicas de promoción para atraer a los usuarios hacia el sitio: •

Banners publicitarios: Ya sea desde sitios web externos pero relacionados temáticamente con el sitio a promocionar, o desde el mismo sitio web cuando lo que se promociona es un sub-sitio o sección interna.

•

Inclusión en buscadores y directorios: La inclusión del sitio web en índices y motores de búsqueda es la técnica más eficiente para atraer usuarios. Si el sitio web es público (de acceso no limitado o controlado) se debe haber diseñado de tal forma que facilite su indización automática. Si el sitio web no es público (por ejemplo un máster virtual), y los contenidos no son accesibles, se debe crear un mini-sitio público que

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

178

explique toda la información posible acerca del sitio, para que este sea indizado por los buscadores. •

Campañas de correo electrónico: Si se posee una base de datos con correos electrónicos de usuarios potenciales (y es legal la posesión y uso de esta información), se puede informar directamente a estos usuarios del lanzamiento del sitio. Otro mecanismo muy útil es la promoción a través del envío de mensajes a listas de correo relacionadas temáticamente con el sitio web.

6.11.

Mantenimiento y seguimiento

Un sitio web no es una entidad estática, es un objeto vivo cuyos contenidos cambian; cuya audiencia, necesidades y perfiles cambian, y que por lo tanto requiere de continuos rediseños y mejoras. Estos rediseños deben ser muy sutiles, no se puede cambiar el aspecto y diseño de forma drástica de un día para otro, pues aunque estos cambios estén fundamentados en problemas de usabilidad descubiertos post-lanzamiento, los cambios pueden resultar dramáticos para los actuales usuarios que ya estaban acostumbrados y familiarizados con el actual diseño. Los problemas de uso no detectados durante el proceso de desarrollo pueden descubrirse a través de varios métodos, principalmente a través de los mensajes y opiniones de los usuarios, y su comportamiento y uso del sitio.

6.12.

Opiniones de los usuarios

Esta información puede ser obtenida de forma pasiva - a través de los mensajes enviados por los usuarios acerca de problemas que han tenido con el uso del sitio - o de forma activa - por medio de cuestionarios y encuestas realizadas sobre la audiencia -. Las opiniones expresadas por los usuarios indican posibles problemas de usabilidad, pero no son en sí mismas la respuesta a estos problemas. Por ejemplo, si un usuario envía un email preguntando por qué desde la home page no encuentra un enlace al recurso X, no significa que debamos implementar este enlace, sino que posiblemente el recurso X sea poco visible o de difícil localización. Igualmente, en los cuestionarios no se deben hacer preguntas del tipo "¿Preferiría que el diseño fuera de tal forma?", sino del tipo "¿Ha tenido algún problema para localizar el recurso X?" ó "¿Le ha resultado fácil el uso de la herramienta X?". Los resultados de los cuestionarios no indican la usabilidad del sitio, sino la satisfacción del usuario. Si la satisfacción es baja, habrá que mejorar la usabilidad.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

179

Comportamiento del usuario y uso del sitio Una vez que el sitio web ha sido lanzado y es usado diariamente, tenemos a nuestra disposición una nueva fuente de información sobre el comportamiento del usuario: Los ficheros "log". Estos, son extensos ficheros de texto plano que genera el servidor web, y en los que se registra cada una de las peticiones de páginas realizadas por los clientes al servidor. Por cada petición del cliente al servidor se suele registrar la siguiente información: • • • • • • • • •

Dirección IP del cliente Identidad del usuario (para sitios con identificación) Password de acceso (para sitios con identificación) Fecha y hora de la petición Método Path o directorio de la página en el servidor Código que indica si la petición ha sido resuelta correctamente o no Número de bytes trasferidos entre cliente y servidor Página desde la que se pide el archivo al servidor (puede ser una URL interna si a la página se llega por un enlace del mismo sitio web, o externa, en el caso de que sea a través de otro sitio web)

Información sobre el agente software (navegador) del cliente A través del análisis de los ficheros logs se pueden responder preguntas como: ¿quién usa el sitio? ¿Cuándo lo usa? ¿Qué páginas suelen ser las más visitadas? ¿Desde qué páginas se llega? ¿Qué términos utiliza el usuario para interrogar al buscador interno?... Se trata realmente de una información muy valiosa que correctamente analizada (normalmente ayudándonos de software específico), puede servirnos para la toma de decisiones sobre el rediseño en sitios web implementados. Back-end, es la parte que procesa la entrada desde el front-end Front-end, es la parte del software que interactúa con el o los usuarios Heurística, capacidad de un sistema para realizar de forma inmediata innovaciones positivas para sus fines

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

180

Glosario GLOSARIO

Abstracción: es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Abstracción: permite concentrarse en un problema al mismo nivel de generalización, independientemente de los detalles irrelevantes de bajo nivel; Actor: Agente externo que realiza una acción sobre el sistema, acción esta que puede ser capturada como un guión que sea parte de un caso de uso. Almacenamiento: Es la representación de un conjunto de datos en reposo, representa archivos, bases de datos, debe tener entrada y salida. Almacenes de datos: conjuntos temporales o permanentes de datos. Ambigüedad: Posibilidad de que algo pueda entenderse de varios modos o de que admita distintas interpretaciones. Análisis: Es una de las etapas del ciclo de vida de un sistema informático. En esta etapa los analistas se encargan de analizar los requerimientos del sistema. Analista de sistema: Persona que hace análisis de sistemas informáticos. Analista programador: Es el responsables del desarrollo del producto en sí; interactúa directamente con el cliente.

Atributo, Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos. Back-end: es la parte que procesa la entrada desde el front-end. Base de datos: una base de datos es una colección integrada de datos almacenados en distintos tipos de registros, de forma que sean accesibles para múltiples aplicaciones. Beans: es un componente hecho en software que se puede reutilizar y que puede ser manipulado visualmente por una herramienta de programación en lenguaje Java. Cardinalidad: Es la especificación del número de ocurrencias de un objeto que puede relacionarse con el número de ocurrencias de otro objeto. Caso de uso: Es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Casos de uso: Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios CGI: (Common Gateway Interface), una tecnología que se usa en los servidores web

Clase: Es simplemente una representación de un tipo de objeto; piense en ella como un plano que describe el objeto. Así como un plano puede utilizarse para construir varios edificios, una clase puede utilizarse para crear varias copias de un objeto. Complejidad: Es la cantidad información de un sistema.

Concurrencia: es la propiedad que distingue un objeto que está activo de uno que no lo está. Controles: estándares y lineamientos para determinar si las actividades están ocurriendo en la forma anticipada o aceptada, es decir, si se encuentran bajo control. Asimismo especificar las acciones que deben emprenderse cuando ocurren problemas o presentan circunstancias inesperadas. CORBA (Common Object Request Broker Architecture, arquitectura común de intermediarios en peticiones a objetos), es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. Datos: los elementos individuales de los archivos se llaman datos, también conocidos como campos. Cada dato se identifica por su nombre y tiene un valor específico asociado a él. DCOM: (Distributed Component Object Model), un sistema de Microsoft. Componentes de un software para comunicarse con computadoras en línea. Diagrama de clase: Es donde se definen las características de cada una de las clases, interfaces, colaboraciones y

relaciones de generalización.

dependencia

Diseño arquitectónico: define la relación entre cada uno de los elementos estructurales del programa. Diseño de datos: trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. Diseño de entrada: entrada describen la manera en que los datos ingresarán al sistema para su procesamiento. Diseño de la Interfaz: describe como se comunica el Software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. Diseño de salida: se refiere a los resultados e información generados por el sistema. Diseño detallado: se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algorítmicas del software. Diseño físico: es el proceso de traducción del modelo lógico abstracto a un diseño técnico específico para el nuevo sistema. Diseño lógico: describe las entradas y salidas, las funciones de procesamiento a realizar, los procedimientos de negocios, los modelos de datos y los controles. Diseño preliminar: se centra en la transformación de los requisitos en los datos y la arquitectura del software. Diseño procedimental: transforma los elementos estructurales en una descripción procedimental del software. Se

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

182

genera el código fuente y, para integrar y validar el software, se llevan a cabo las pruebas.

Hardware: Componente físico tecnológico, que trabaja o interactúa de algún modo con la computadora.

Diseño: es el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física.

Herencia: Es un mecanismo que permite definir nuevas clases a partir de otras ya definidas de modo que si en la definición de una clase se indica que ésta deriva de otra, entonces la primera “a la que se le suele llamar clase hija” será tratada por el compilador automáticamente como si su definición incluyese la definición de la segunda.

Encapsulación: en el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus características esenciales. Encapsulado: Conjunto de datos y métodos. El objeto esconde sus datos de los demás objetos y permite el acceso a los datos mediante sus propios métodos. Esto recibe el nombre de ocultamiento de la información Entidad: Es la representación de un objeto o concepto del mundo real que se describe en una base de datos. Estereotipo: Es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensión del modelo. Flujo de dato: Es la representación de datos en movimiento mediante flechas, no hay datos distinto con el mismo nombre.

Heurística: capacidad de un sistema para realizar de forma inmediata innovaciones positivas para sus fines. Información: Conjunto organizado de datos procesados, que constituyen un mensaje sobre un determinado ente o fenómeno. Información: Conjunto organizado de datos procesados, que constituyen un mensaje sobre un determinado ente o fenómeno. Ingeniería: Profesión que aplica conocimientos y experiencias para que mediante diseños, modelos y técnicas, se resuelvan problemas que afectan a la humanidad.

Flujos de datos: movimientos de datos hacia, alrededor y desde el sistema.

Ingeniería: Profesión que aplica conocimientos y experiencias para que mediante diseños, modelos y técnicas, se resuelvan problemas que afectan a la humanidad.

Front-end: es la parte del software que interactúa con el o los usuarios

Jerarquía o herencia: es el orden de las abstracciones organizado por niveles.

Gestión: Conjunto de trámites que se llevan a cabo para resolver un asunto

Los requerimientos funcionales, definen las funciones que el software será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

183

Los requerimientos no funcionales, tienen que ver con características que de una u otra forma puedan limitar el sistema

Obtención: Logro, consecución de un objetivo: obtener información de parte del cliente.

Mantenimiento: Es una de las etapas del ciclo de vida de un sistema informático. En esta etapa se realizan los cambios, e implementación y resolución de anomalías

Organización: Es un sistema de actividades conscientemente coordinadas formado por dos o más personas; la cooperación entre ellas es esencial para la existencia de la organización.

Metaclase, Es una clase cuyas instancias son clases. Sirven como depósito para mantener las variables de clase y proporcionan operaciones (método de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos). Metamodelo: Es cada una de las distintas clases de modelos de situaciones problemáticas presentadas a la actividad del humano, capaces de generar ideas validas para la invención, reconstrucción y resolución de problemas. Método: También conocido como operación, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza. Modularidad: es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes. MTS: (Message Telecommunications Service), servicio de mensaje. Negocio: Provecho o ganancia que se obtiene en lo que se trata o comercia Objeto de datos: Es una representación de cualquier información compuesta que el software debe entender.

Persistencia: es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado). Personal de mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Personal de prueba: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Procedimientos: métodos y rutinas para utilizar el sistema de información y lograr con ello los resultados esperados. Procesos: actividades para aceptar, manejar y suministrar datos e información. Pueden ser anuales o basadas en computadora. Procesos: Muestran una parte del sistema que transforma datos de entrada en datos de salida, se describen con una sola frase sencilla: Verbo – Objeto Proyecto: Es una empresa planificada que consiste en un conjunto de actividades

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

184

que se encuentran interrelacionadas y coordinadas. Rastreabilidad: Posibilidad de seguir el historial, la utilización o la localización de un elemento o de una actividad. Rastreabilidad: Posibilidad de seguir el historial, la utilización o la localización de un elemento o de una actividad Refinamiento: es un proceso de elaboración. Donde se comienza con una declaración de la función (o una descripción de la información) definida a un nivel superior de abstracción. Registro: un registro es el conjunto completo de datos relacionados pertenecientes a una entrada. Requerimiento: en la ingeniería de sistemas, es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Requerimiento: en la ingeniería del software, es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Riesgo: Cualquier provocar daños

cosa

que

pueda

Sistema: Conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. Software: Conjunto de instrucciones codificada para ser leídas interpretada por una computadora. Tipificación: es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.

Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementación. Un tipo establece una especificación de comportamiento para las clases. Transacción: Es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir en forma indivisible, o atómica. UML: Es un conjunto de herramientas, que permite modelar (analizar y diseñar) sistemas orientados a objetos. Usuario: Individuo que utiliza una computadora, sistema operativo, servicio o cualquier sistema informático. Usuarios Administrativos: son aquellos que tienen responsabilidades en la administración de los sistemas de aplicación. Usuarios directos: son quienes realmente interactúan con el sistema, ellos alimentan (ingresan) datos o reciben salidas (informes). Usuarios final: Son las personas que usarán el sistema desarrollado. Usuarios Indirectos: son aquellos que se benefician de los resultados o informes producidos por el sistema, pero no interactúan directamente con el hardware o el software. Usuarios Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Validar: Dar crédito a un documento especifico que contiene los requerimientos del sistema propuesto.

Tecnológico de Antioquia Institución Universitaria Vicerrectoría Académica

185

Bibliografía

1. Booch, Grady. Análisis y Diseño Orientado a Objetos. Ed. Addison – Wesley/Díaz de Santos. 2da. edición, 1996. 2. Fowler, Martín. “UML Gota a Gota”. Primera edición. Addison Wesley Longman. 1999. 3. James A. Senn. Análisis y Diseño de Sistemas de información. Edición. 1988. McGrawHill/Interamericana de México, S.A. de C.V 4. Martín, James y James J. Odell. Análisis y Diseño Orientado a Objetos. Ed. Prentice Hill. 1ra. Edición. 1994. 5. Martín, James y James J. Odell. Análisis y Diseño Orientado a Objetos. Ed. Prentice Hill. 1ra. Edición. 1994. 6. Pressman, Roger S. “Ingeniería del Software”. Un enfoque practico Sexta Edición, México McGraw Hill, 2006. 7. Pressman, Roger S. “Ingeniería del Software”. Un enfoque practico Sexta Edición, México McGraw Hill, 2006. 8. Pressman, Roger S. Ingeniería del Software. Ed. McGraw- Hill. 1998. 9. Senn, James A. Análisis y Diseño de Sistemas de Información. Segunda Edición. McGraw Hill. 1992. 10. Stephen, R. Schach. Análisis y Diseño Orientado a Objetos. Con UML y el Proceso Unificado, Mexico McGraw Hill 2004 11. Stephen, R. Schach. Ingenieria de Software Clásica y Orientada a Objetos. Sexta Edición Mexico McGraw Hill 2006 12. Whitten, Jeffrey L., Lonnie D Bentley, Victor M. Barlow. Análisis y diseño de sistemas de información. Ed. McGraw-Hill, 3ra.ed. 1998

Cibergrafﾃｭa

HISTORIA DE LA INGENIERIA DEL SOFTWARE. Tomado de internet el 29 de agosto de 2008. Hora 11:20 p.m. http://www.um.es/docencia/barzana/IAGP/IAGP2-Ingenieriasoftware-introduccion.html OBJETIVOS DE LA INGENIERIA DEL SOFTWARE. Tomado de internet el 16 de junio de 2007. Hora 11:00 am. http://www.monografias.com/trabajos5/inso/inso.shtml#obje IEEE Task Force on Requirements Engineering. http://www.shu.ac.uk/tfre/web.links.html Publicaciones de Elsevier Science. http://www.elsevier.nl/ Software Engineering Resources by Roger S. Pressman & Associates Inc. http://www.rspa.com/spi/index.html DISEﾃ前 WEB. Tomado de internet el 19 de noviembre de 2008. Hora 11:00 am. http://redc.revistas.csic.es/index.php/redc/article/view/156/0